Nginx answers too large requests with bad status

Tue Oct 30 00:57:40 UTC 2012

@Valentin
I am not seeking a solution to the 414 problem, I know how to address the
issue
Thanks anyway

@Francis
The browser output has just be made to illustrate the wrong answer.

The problem triggered using a Python script which checked against the
'status' field of a HTTP answer to decide on its actions.
It crashed several times at random occurences with a BadStatusLine
exception.
The exception message was something like '<html>\n\n\n\n200'.

I do not know the implementation details, although I suspect an answer code
should be an answer code.
I didn't get 414, I get something which made my script crash.

That's why I guess that's a bug
---
*B. R.*

On Mon, Oct 29, 2012 at 8:12 PM, Francis Daly <francis at daoine.org> wrote:

> On Mon, Oct 29, 2012 at 07:43:27PM -0400, B.R. wrote:
>
> Hi there,
>
> > When submitting too large requests, Nginx replies a page containing the
> > right code status but serves the errors page with a HTTP/0.9 (!) 200
> answer.
>
> No, it doesn't.
>
> Look at the "curl -i" output.
>
> Your browser is making up the 200 status.
>
> It is right about the HTTP/0.9 response, though, because nginx couldn't
> see that the request was HTTP/1.0 or HTTP/1.1. And therefore it "knows"
> that it was HTTP/0.9.
>
> See the thread including http://forum.nginx.org/read.php?2,228425,228431
> for more details.
>
> I think that nginx is not wrong in this case. But I also think that it
> wouldn't be wrong if this HTTP/0.9 response had two paragraphs, and began
> with the characters "HTTP/1.1 414".
>
> I imagine that if someone provided a justification with a patch, it
> would be considered like any other suggested patch.
>
>         f
> --
> Francis Daly        francis at daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20121029/64075f98/attachment.html>