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 2012-10-30 01:08
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 -- http://nginx.com/support.html http://nginx.org/en/donation.html
on 2012-10-30 01:12
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@daoine.org
on 2012-10-30 01:59
@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 2012-10-30 02:10
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 '<html>'. 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 2012-10-30 10:18
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 -- http://nginx.com/support.html http://nginx.org/en/donation.html
on 2012-10-30 15:09
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 2012-10-30 21:10
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 Daly francis@daoine.org
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.