# Nginx answers too large requests with bad status

**URL:** <https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085>\
**Category:** NGINX\
**Created:** [October 30, 2012, 12:44am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085 "2012-10-30T00:44:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [October 30, 2012, 12:44am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/1 "2012-10-30T00:44:51Z")

</div>

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._

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 1:08am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/2 "2012-10-30T01:08:16Z")

</div>

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”.

> **[Module ngx\_http\_core\_module](http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers)**
>
> This directive appeared in version 1.11.8.

wbr, Valentin V. Bartenev

–

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.

> **[nginx: donation](http://nginx.org/en/donation.html)**

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 1:12am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/3 "2012-10-30T01:12:57Z")

</div>

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](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 D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 2:10am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/4 "2012-10-30T02:10:18Z")

</div>

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._

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 10:18am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/5 "2012-10-30T10:18:41Z")

</div>

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

–

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.

> **[nginx: donation](http://nginx.org/en/donation.html)**

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 3:09pm UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/6 "2012-10-30T15:09:57Z")

</div>

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._

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 9:10pm UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/7 "2012-10-30T21:10:42Z")

</div>

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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\
**Post date:** [October 30, 2012, 1:59am UTC](https://www.ruby-forum.com/t/nginx-answers-too-large-requests-with-bad-status/224085/8 "2012-10-30T01:59:12Z")

</div>

@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._
