411 Length Required error

[Maxim Dounin]

Hello!

On Thu, Aug 20, 2009 at 02:46:00AM +0200, Evert | FM wrote:

> Hey guys,
> 
> I'm the author of SabreDAV (http://code.google.com/p/sabredav/) and
> today I got a bug report regarding Nginx.
> 
> Finder will do a PUT request in some cases, without a Content-Length
> header. It does send the data 'Chunked'.
> As far as I can tell this is a legal request for HTTP/1.1.
> 
> I've noticed this question has been asked a few times on this list,
> but I could not find satisfying answer or bug tracker. Is there a bug
> tracker of some sort for Nginx?
> 
> Are you guys aware of this issue?

As of now nginx does not support chunked request body.  We are 
aware of this.

RFC 2616 says:

   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
   containing a message-body MUST include a valid Content-Length header
   field unless the server is known to be HTTP/1.1 compliant. If a
   request contains a message-body and a Content-Length is not given,
   the server SHOULD respond with 400 (bad request) if it cannot
   determine the length of the message, or with 411 (length required) if
   it wishes to insist on receiving a valid Content-Length.

For me it looks like such requests valid if and only if server is 
known for sure to be HTTP/1.1 and anyway client should be prepared 
to get 411 back.

This doesn't mean that there is no plan to support it (at least 
some java clients known to use it too), but it's not really high 
priority task.

> There was another issue (less important), but I wanted to throw it out
> there. When a request (such as MOVE) generates an empty response-body,
> and there is no Content-Length, nginx will effectively hang until the
> HTTP keepalive timeout is reached. This was easily fixed by adding
> Content-Length: 0, but I wanted to mention it because Apache adds this
> automatically, so it might help for better compatibility. Note that
> this is all PHP.

If there is no Content-Length in response nginx will use 
Transfer-Encoding: chunked in the reply (or connection close for 
HTTP/1.0 requests), and this shouldn't break anything.

Could you please provide some more details on the problem you see?  
For now it looks like client issue instead.

> The last one, but this might have been fixed. I tested Nginx a while
> back, and it didn't seem to have support for the Expect: 100-continue
> header. I'm just curious if this has been fixed since then. I've
> noticed certain .NET HTTP clients use this header.

Support for "Expect: 100-continue" appeared in nginx 0.7.4.

Maxim Dounin