Forum: NGINX Nginx answers too large requests with bad status

1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2012-10-30 00:44
(Received via mailing list)
Attachment: 414_200.png (10 KB)
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.*
C9264ddbc4a782fff755b0125364cbdf?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2012-10-30 01:08
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-10-30 01:12
(Received via mailing list)
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
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2012-10-30 01:59
(Received via mailing list)
@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.*
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2012-10-30 02:10
(Received via mailing list)
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.*
C9264ddbc4a782fff755b0125364cbdf?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2012-10-30 10:18
(Received via mailing list)
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
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2012-10-30 15:09
(Received via mailing list)
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.*
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-10-30 21:10
(Received via mailing list)
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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.