Hello,
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.
Screenshot as attachment.
Have a nice evening,
B. R.
On Tuesday 30 October 2012 03:43:27 B.R. wrote:
Hello,
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. Screenshot as attachment.
You should tune “large_client_header_buffers”.
http://nginx.org/r/large_client_header_buffers
wbr, Valentin V. Bartenev
–
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 Re: nginx/1.3.2 - 4xx responses are returned without HTTP headers, bug?
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 D. [email protected]
To avoid saying odd things, the only think I am sure of when I checked
the
exception output from Python is that it started with ‘’. Maybe the
rest of the output came from my script.
I am not at work any more I can’t check.
The only thing I am pretty sure about is that the status must be a
status
like ‘200 OK’ or ‘414 WTHAreYouDoin’.
I hate Python, but I’ll trust it on that one ^^
I’ll try to make a little PoC if needed,
B. R.
On Tuesday 30 October 2012 04:57:40 B.R. wrote:
[…]
There’s no Status-Line in HTTP/0.9. So, the problem is that your script
do not
support HTTP/0.9.
wbr, Valentin V. Bartenev
–
Alright, I got it now.
That’s because the protocol defines its version after the request
address… which is already too long to be fully read.
Thanks for your help!
No bug in Nginx indeed :o)
I’ll go set up better buffers,
B. R.
On Tue, Oct 30, 2012 at 10:08:38AM -0400, B.R. wrote:
Hi there,
Alright, I got it now.
That’s because the protocol defines its version after the request
address… which is already too long to be fully read.
Correct. Your script thought it made a HTTP/1.1 request, and expected
a HTTP/1.1 response.
nginx thought your script made a HTTP/0.9 request, and provided a
HTTP/0.9 response.
When something expects a HTTP/1.1 response and gets a HTTP/0.9 response,
bad things can happen unless it was written defensively.
Thanks for your help!
No bug in Nginx indeed :o)
I’d say not a bug, but an inconvenience.
I imagine that the cost to the HTTP/0.9 clients of seeing an extra
“”"
HTTP/1.0 414 No
“”"
at the start of this response is less than the cost to the HTTP/1.x
clients of not seeing those two lines.
But until someone who cares does the work, the cost to nginx of changing
the current behaviour is unknown, but certainly non-zero.
I’ll go set up better buffers,
Yes. The buffers should be set to include all requests that you wish
to accept. If your system uses particularly big requests, then you
need big buffers.
Cheers,
f
Francis D. [email protected]
@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 ‘\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.