Forum: NGINX 411 Length Required error

Posted by Chris Savery (Guest)
on 2008-08-17 09:22
(Received via mailing list)
Hello,
I've been getting this error a lot in my testing. I never received it
with Apache. I understand what the message say but not why it's coming
about. My headers being sent have length. Or is this message referring
to content returned by PHP at the server end? I'm sure one of you
experts here knows what's going on with this. I only get it on POST
requests and not most of my ajax calls (which are GET).

Thanks for any help with tracking this down. I'm seeing it in Firebug
and when it occurs I cannot see the real response content - even though
content is indeed returned as well since it has effect on my javascript
code and updates the screen. Weird.
Chris :)

Response from server:

<html>

<head><title>411 Length Required</title></head>

<body bgcolor="white">

<center><h1>411 Length Required</h1></center>

<hr><center>nginx/0.6.32</center>

</body>

</html>

Header sent to server using ajax (only removed some identity info, HOST 
line):

User-Agent   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1)
Gecko/2008072820 Firefox/3.0.1
Accept   text/javascript, text/html, application/xml, text/xml, */*
Accept-Language   en-us,en;q=0.5
Accept-Encoding   gzip,deflate
Accept-Charset   ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive   300
Connection   keep-alive
X-Requested-With   XMLHttpRequest
Content-Type   application/x-www-form-urlencoded; charset=utf-8
Referer   http://www.xxxxx.com/
Content-Length   269
Cookie   ZZZZSession=3ce34bb3dbc257ff61405175f941f1d7
Pragma   no-cache
Cache-Control   no-cache
Posted by Igor Sysoev (Guest)
on 2008-08-17 09:30
(Received via mailing list)
On Sun, Aug 17, 2008 at 02:14:18PM +0700, Chris Savery wrote:

> code and updates the screen. Weird.
> Chris :)

Set error_log level to info:

error_log  /path/to/log info;

Then nginx will log a reason. Now there are 3 reasons:

"client sent invalid "Content-Length" header"
"client sent ... method without "Content-Length" header"
"client sent "Transfer-Encoding: chunked" header"

The last reason is nginx feature: it still does not support chunked 
body.
Posted by Chris Savery (Guest)
on 2008-08-17 15:51
(Received via mailing list)
Thanks Igor.

I turned on info and it says the reason is client didn't send
"Content-Length" header. Now, why would Firefox (3) not do that? Is this
common?

I noticed in Firebug that the header sent ALSO has "Transfer-Encoding:
chunked".
I had the same problem with Lightpd and using a Flash uploader but they
refuse to fix it to ignore chunked, so I could not use it with Flash.
One reason I switched to using nginx is that unlike Lighttpd it works
with the flash uploader.

So should I just ignore this as it still works as expected?  But I
cannot see content in Firebug, or maybe I need to force a header in JS
code (maybe the mootools JS library mistakenly doesn't set the Content
Length hmm, I should explore that too.) Just a minefield. How is it that
the server returns this error page but also I am getting the JSON data
back as well?

Chris :)
Posted by Chris Savery (Guest)
on 2008-08-17 16:00
(Received via mailing list)
My mistake on that last message. I read the wrong headers info.
It seems ngninx reports no Content-Length header was sent but according
to Firebug these are the headers - note it says Content Length is
present and chunked not mentioned...

Host   www.xxxx.com
User-Agent   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1)
Gecko/2008072820 Firefox/3.0.1
Accept   text/javascript, text/html, application/xml, text/xml, */*
Accept-Language   en-us,en;q=0.5
Accept-Encoding   gzip,deflate
Accept-Charset   ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive   300
Connection   keep-alive
X-Requested-With   XMLHttpRequest
Content-Type   application/x-www-form-urlencoded; charset=utf-8
Referer   http://www.xxxx.com/
Content-Length   120
Cookie   XXXXXSession=3ce34bb3dbc257ff61405175f941f1d7
Pragma   no-cache
Cache-Control   no-cache
Posted by Igor Sysoev (Guest)
on 2008-08-17 16:03
(Received via mailing list)
On Sun, Aug 17, 2008 at 08:53:55PM +0700, Chris Savery wrote:

> Accept-Encoding   gzip,deflate
> Accept-Charset   ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive   300
> Connection   keep-alive
> X-Requested-With   XMLHttpRequest
> Content-Type   application/x-www-form-urlencoded; charset=utf-8
> Referer   http://www.xxxx.com/
> Content-Length   120
> Cookie   XXXXXSession=3ce34bb3dbc257ff61405175f941f1d7
> Pragma   no-cache
> Cache-Control   no-cache

Then only nginx debug log or tcpdump will help.
Posted by Igor Sysoev (Guest)
on 2008-08-17 16:11
(Received via mailing list)
On Sun, Aug 17, 2008 at 08:40:39PM +0700, Chris Savery wrote:

> One reason I switched to using nginx is that unlike Lighttpd it works 
> with the flash uploader.
> 
> So should I just ignore this as it still works as expected?  But I 
> cannot see content in Firebug, or maybe I need to force a header in JS 
> code (maybe the mootools JS library mistakenly doesn't set the Content 
> Length hmm, I should explore that too.) Just a minefield. How is it that 
> the server returns this error page but also I am getting the JSON data 
> back as well?

nginx tests Content-Length absence before Transfer-Encoding, thus
it logs this error, although the request is valid: it has either
Transfer-Encoding or Content-Length.
Posted by Chris Savery (Guest)
on 2008-08-18 02:12
(Received via mailing list)
Ok. I used Wireshark and tracked this down. I'm posting here so that
others will know why this happens. It is a result of poor behaviour in
Firebug.

In fact, if you click on the log tab to view request data and headers
then Firebug actually re-submits the POST data a second (hidden) time to
provide data to show you. Of course, since POST methods will update
server data and could insert new database rows this is very bad of
Firebug. It is treating the POST like a GET in this case where it should
have logged the original POST reply data instead. I have posted a bug in
their google group and hopefully someday they will give it some 
attention.

When Firebug submits the second time it does NOT include the
Content-Length header as it did at first, but it shows as though it did.
This is why my page was correctly updated but an 411 error was shown in
the Firebug log. The original response was not saved and the error was
from the repeated POST request.

Just something for people to be aware of.

Chris :)
Posted by Caesar Indra (suntzu)
on 2008-08-18 06:01
Hi all

I'm having a similar issue. In Firebug, the Request Headers 
Content-Length shows 112. However, I got the 411 Content Length Required 
response.

Does any of the experts here know what's going on? Thanks in advance!

Request Headers
Host  www.xxxxx.com
User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; 
rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language  en-us,en;q=0.5
Accept-Encoding  gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  300
Connection  keep-alive
X-Requested-With  XMLHttpRequest
Content-Type  application/x-www-form-urlencoded; charset=UTF-8
Referer  http://www.xxxxxx.com/people/1/edit
Content-Length  112
Cookie 
_xxxxxx_session=BAh7CjoPbGFzdF9sb2dpbnU6CVRpbWUNhh0bgAAAEI86EHJlcXVlc3RfdXJp%250AMDoMY3NyZl9pZCIlNWM1ZmYxZjlmZWQ2YmJmNTM2YWJlOGQwOGE0MjhkZDIi%250ACmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7%250AAAY6CkB1c2VkewA6CXVzZXJvOjVBY3RpdmVSZWNvcmQ6OkFzc29jaWF0aW9u%250Aczo6QmVsb25nc1RvQXNzb2NpYXRpb24JOgtAb3duZXJvOgtEZXRhaWwIOgxA%250AcGVyc29uQAs6EEBhdHRyaWJ1dGVzewsiFXdvcmxkX3Zpc2liaWxpdHkiD2V2%250AZXJ5dGhpbmciFWluZm9ybWF0aW9uX3R5cGUiEUVtYWlsQWRkcmVzcyIPdXBk%250AYXRlZF9vbiIYMjAwOC0wOC0wNCAwNTo0OToxNSIHaWQiBjIiE2luZm9ybWF0%250AaW9uX2lkIgYxIg5wZXJzb25faWQiBjE6FkBhdHRyaWJ1dGVzX2NhY2hlewA6%250ADEBsb2FkZWRUOgxAdGFyZ2V0bzoJVXNlchc6JUBkZXRhaWxfbWVtYmVyc2hp%250AcF9yZWxhdGlvbnNoaXBzMDopQHVzZXJfcHJvZmlsZV9lbWFpbF9hZGRyZXNz%250AX3JlcXVlc3RzMDoTQGhpc3RvcnlfaXRlbXMwOxB7CiIPYWNjb3VudF9pZCIG%250AMSIVb3B0aW9uYWxfZGF0ZV9pZDAiCXR5cGUiCVVzZXIiB2lkIgYxIgxuYW1l%250AX2lkIgYxOg1AYWNjb3VudDA6KEB1c2VyX3Byb2ZpbGVfZW1haWxfYWRkcmVz%250Ac19yZXF1ZXN0MDoNQGRldGFpbHMwOiNAZGV0YWlsX2VtYWlsX2FkZHJlc3Nf%250AcmVxdWVzdHMwOhBAYmlydGhfZGF0ZTA6FEBncm91cHNfbWFuYWdlZDA6HEBl%250AbWFpbF9hZGRyZXNzX3JlcXVlc3RzMDodQG1hbmFnZXJfc3RhdHVzX3JlcXVl%250Ac3RzMDsRewA6DEBncm91cHMwOitAZGVsZXRlX3ByaW1hcnlfZW1haWxfYWRk%250AcmVzc19yZXF1ZXN0czA6EUBtZW1iZXJzaGlwczA6IUBncm91cF9tYW5hZ2Vy%250AX3JlbGF0aW9uc2hpcHMwOgpAbmFtZTA6EEByZWZsZWN0aW9ubzo0QWN0aXZl%250AUmVjb3JkOjpSZWZsZWN0aW9uOjpBc3NvY2lhdGlvblJlZmxlY3Rpb24NOhhA%250AdGhyb3VnaF9yZWZsZWN0aW9uRjoTQGFjdGl2ZV9yZWNvcmRjC0RldGFpbDoQ%250AQGNsYXNzX25hbWUiC1BlcnNvbjoLQGtsYXNzYwtQZXJzb246C0BtYWNybzoP%250AYmVsb25nc190bzoNQG9wdGlvbnN7ADskOgtwZXJzb246FkBwcmltYXJ5X2tl%250AeV9uYW1lIg5wZXJzb25faWQ%253D--2bd2eb7eff4dcf6d5f1b8290df567298516fbfe9; 
connection=efa9ce4469ee3f84e8488d939c6e82d4; email_address=xxx%40xxx.com



Chris Savery wrote:
> Ok. I used Wireshark and tracked this down. I'm posting here so that
> others will know why this happens. It is a result of poor behaviour in
> Firebug.
> 
> In fact, if you click on the log tab to view request data and headers
> then Firebug actually re-submits the POST data a second (hidden) time to
> provide data to show you. Of course, since POST methods will update
> server data and could insert new database rows this is very bad of
> Firebug. It is treating the POST like a GET in this case where it should
> have logged the original POST reply data instead. I have posted a bug in
> their google group and hopefully someday they will give it some 
> attention.
> 
> When Firebug submits the second time it does NOT include the
> Content-Length header as it did at first, but it shows as though it did.
> This is why my page was correctly updated but an 411 error was shown in
> the Firebug log. The original response was not saved and the error was
> from the repeated POST request.
> 
> Just something for people to be aware of.
> 
> Chris :)
Posted by Rocky Zhang (rockyzh)
on 2008-11-28 09:46
Posted by Igor Sysoev (Guest)
on 2008-11-28 10:16
(Received via mailing list)
On Fri, Nov 28, 2008 at 09:46:34AM +0100, Rocky Zhang wrote:

> Here is a solution:
> http://yonggang.blog.kingtch.com/2008/11/28/fix_ng...

The patch is wrong, it simply drops chunked body.
Posted by Rocky Zhang (rockyzh)
on 2008-11-28 16:26
Yes. If there is no chunked body, it works fine. If there is, we could 
check its request header information and close it if we haven't 
implemented chunked body feature. Could we patch it?


Igor Sysoev wrote:
> On Fri, Nov 28, 2008 at 09:46:34AM +0100, Rocky Zhang wrote:
> 
>> Here is a solution:
>> http://yonggang.blog.kingtch.com/2008/11/28/fix_ng...
> 
> The patch is wrong, it simply drops chunked body.
Posted by Rocky Zhang (rockyzh)
on 2008-11-28 16:50
  I've updated the patch in this way. you can check it in the same blog 
post.

Rocky Zhang wrote:
> Yes. If there is no chunked body, it works fine. If there is, we could 
> check its request header information and close it if we haven't 
> implemented chunked body feature. Could we patch it?
> 
> 
> Igor Sysoev wrote:
>> On Fri, Nov 28, 2008 at 09:46:34AM +0100, Rocky Zhang wrote:
>> 
>>> Here is a solution:
>>> http://yonggang.blog.kingtch.com/2008/11/28/fix_ng...
>> 
>> The patch is wrong, it simply drops chunked body.
Posted by Igor Sysoev (Guest)
on 2008-11-28 17:04
(Received via mailing list)
On Fri, Nov 28, 2008 at 04:26:29PM +0100, Rocky Zhang wrote:

> Yes. If there is no chunked body, it works fine. If there is, we could 
> check its request header information and close it if we haven't 
> implemented chunked body feature. Could we patch it?

I do not understand what yuo want to get.

Currently nginx does not support a chunked request body and returns
411 error code for such requests.

Also nginx returns the 411 error if a POST/PUT request has no 
"Content-Length".
If the request has no body, then it must send "Content-Length: 0".
Posted by Rocky Zhang (rockyzh)
on 2008-11-29 03:15
Unfortunately I found that when I use POST method to request an AJAX 
function, the browser sends a request with neither body nor 
"Content-Length: 0".

Igor Sysoev wrote:
> On Fri, Nov 28, 2008 at 04:26:29PM +0100, Rocky Zhang wrote:
> 
>> Yes. If there is no chunked body, it works fine. If there is, we could 
>> check its request header information and close it if we haven't 
>> implemented chunked body feature. Could we patch it?
> 
> I do not understand what yuo want to get.
> 
> Currently nginx does not support a chunked request body and returns
> 411 error code for such requests.
> 
> Also nginx returns the 411 error if a POST/PUT request has no 
> "Content-Length".
> If the request has no body, then it must send "Content-Length: 0".
Posted by Dave Cheney (Guest)
on 2008-12-01 15:41
(Received via mailing list)
It sounds like that browser is not spec compliant. You may have to
fake a body by sending a form encoded parameter just to generate a
dummy body.

Dave
Posted by Igor Sysoev (Guest)
on 2008-12-01 15:48
(Received via mailing list)
On Tue, Dec 02, 2008 at 01:34:36AM +1100, Dave Cheney wrote:

> It sounds like that browser is not spec compliant. You may have to  
> fake a body by sending a form encoded parameter just to generate a  
> dummy body.

It seems that Apache allowed always such requests (POSTs without
Content-Length). I'm not sure should I add this ?
Posted by Rocky Zhang (rockyzh)
on 2008-12-01 17:33
  I think AJAX will work well with nginx if you add this. Maybe my patch 
may do a little thing for you? FYI, this problem will happen on both IE 
7 and Firefox 3.0.4.


Igor Sysoev wrote:
> On Tue, Dec 02, 2008 at 01:34:36AM +1100, Dave Cheney wrote:
> 
>> It sounds like that browser is not spec compliant. You may have to  
>> fake a body by sending a form encoded parameter just to generate a  
>> dummy body.
> 
> It seems that Apache allowed always such requests (POSTs without
> Content-Length). I'm not sure should I add this ?
Posted by Dave Cheney (Guest)
on 2008-12-02 01:46
(Received via mailing list)
> It seems that Apache allowed always such requests (POSTs without
> Content-Length). I'm not sure should I add this ?

Looking into the RFC's it looks like Apache might be doing the right 
thing.

RFC1945:

   A valid Content-Length is required on all HTTP/1.0 POST requests. An
   HTTP/1.0 server should respond with a 400 (bad request) message if it
   cannot determine the length of the request message's content.

RFC2616:

   The presence of a message-body in a request is signaled by the 
inclusion

   of a Content-Length or Transfer-Encoding header field in the 
request's
message-headers

So,

POST /someurl HTTP/1.1
Host: whatever
\r\n
\r\n

Is a valid post request, but only in the case that the request does not
contain a body. If the post does contain a body, then it must be 
identified
as such with a Content-Lenth: header.

Cheers

Dave
Posted by Mark Moseley (Guest)
on 2008-12-02 02:18
(Received via mailing list)
On Mon, Dec 1, 2008 at 6:38 AM, Igor Sysoev <is@rambler-co.ru> wrote:

> It seems that Apache allowed always such requests (POSTs without
> Content-Length). I'm not sure should I add this ?
>


I can vouch that we've been bitten by that before with AJAX, during
switchovers from straight Apache to nginx reverse proxying for Apache.
We've got a much bigger switchover in the works and I've though about
removing NGX_HTTP_POST from src/http/ngx_http_request.c (line 1414 in
0.7.22, so it'd just apply to PUT). Having a switch to turn off the No
Content Length check for POSTs would be most excellent.
Posted by Igor Sysoev (Guest)
on 2008-12-02 10:36
Attachment: patch.post_wocl (600 Bytes)
(Received via mailing list)
On Mon, Dec 01, 2008 at 05:08:50PM -0800, Mark Moseley wrote:

> Content Length check for POSTs would be most excellent.
I thought about the same, here is patch.
Posted by Loren D. (loren_d)
on 2011-12-16 01:29
Cannot update status. Can someone tell me in laymans terms what 
"chunked' means to them.
Posted by Loren D. (loren_d)
on 2011-12-16 01:30
W.T.F. ?
Please 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
No account? Register here.