411 Length Required error

Server NGINX
1

Hey guys,

I’m the author of SabreDAV (Google Code Archive - Long-term storage for Google Code Project Hosting.) 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?

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.

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.

Evert

2

Hello!

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

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

3

On 20-Aug-09, at 10:11 AM, Maxim D. wrote:

Finder will do a PUT request in some cases, without a Content-Length
header. It does send the data ‘Chunked’.
[…snip…]
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.

It’s good news this is on your radar. For now Finder + Nginx for
WebDAV is simply not compatible.
Do you guys have a project management tool where this stuff is
tracked? I’d like to keep tabs if there’s updates in the future.

I’ve also sent a bug report to Apple.

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.

This is the exact email from the mailing list. If needed I can request
more information:

I have a large delay after MOVE requests when using Mac OSX. It was
exactly the same time as my keepalive timeout, so I tested using an
alternative client (cadaver) and the same thing - MOVE request would
occur immediately, the HTTP response would be sent, again immediately,
but the client would hang until the server timed out the connection
(in my case 75 seconds). Both Finder and Cadaver showed the same
thing.
When I disabled keep alive on nginx, the MOVE request was picked up
immediately.

What’s wrong here? Do I have to disable keep alive?

I also noticed that the spec says to return a Location header, which
isn’t there. That doesn’t appear to be an issue though. If you want to
put it in it’s in the httpMove function after the sendStatus line.

$this->httpResponse->setHeader(‘Location’, $this->httpRequest-

getHeader(‘Destination’));

Here’s the request and response …
x.y.z.a.56253-x.y.z.b.00080: MOVE /dav/test/sub2 HTTP/1.1
Host: dav.example.com
User-Agent: cadaver/0.23.2 neon/0.28.4
Connection: TE
TE: trailers
Destination: http://dav.example.com/dav/test/sub
Overwrite: T
Authorization: Basic YiulnLlkjlkz

x.y.z.a.00080-x.y.z.b.56253: HTTP/1.1 201 Created
Server: nginx/0.7.61
Date: Wed, 19 Aug 2009 00:26:08 GMT
Content-Type: text/html
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.10-pl0-gentoo

[client hangs here for 75 seconds, then suceeds]

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.

Thanks very much for your quick responses! Good to hear this one was
fixed.

Evert