11

I'm getting a 411 status back from nginx when trying to do a PUT without specifying the content-length. Is there any way to disable this from happening?

3 Answers 3

10

You could try to add this to your query :

curl -i -X PUT -H 'Content-Length: 0' 'http://www.example.com/test'

Try to install the HttpChunkinModule or update Nginx to 1.3.9+

This module is no longer needed for Nginx 1.3.9+ because since 1.3.9, the Nginx core already has built-in support for the chunked request bodies.

5

PUT requests require Content-Length. It's not Nginx, it's HTTP that's making this requirement. PUT request, like POST requests, necessarily have a content body. That body can be zero-length, but if it is then you have to explicitly say so. Obviously you can't assume that the content continues until the connection is closed (which is what an absent content-length header implies), because the server has to be able to respond to the request before the connection is closed.

1
  • 3
    this is incorrect. w3.org/Protocols/rfc2616/rfc2616-sec4.html "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." This is a bug in nginx that is fixed in more recent versions. Note that this bug was fixed for POST long before PUT. Mar 28, 2013 at 2:51
2

Old-ish question, but since I stumbled into this from a web search:

NginX 1.3.9 and above supports "Transfer-Encoding: chunked" out of the box for POST and PUT.

With chunked transfer, you can send files without setting content-length first.

1
  • Yep that fixed it, thanks!
    – rogerdpack
    Aug 16, 2019 at 21:09

You must log in to answer this question.