Issue #650 resolved

PUT request with empty body/params ignored

Anonymous avatarAnonymous created an issue

Running 2.2.1 on MacOSX 10.4, I find that a PUT request is ignored (little or no processing, no entry in the log) if it has neither parameters nor an entity body.

For instance, running helloworld from the tutorial, GET works fine:

curl http://localhost:8080/ ==>  Hello world!

but an "empty PUT" gets nada:

curl -X PUT http://localhost:8080/  ==> nothing 
curl -X PUT http://localhost:8080/foobar ==> nothing

A "non-empty PUT" gets more expected results:

curl -X PUT -d 'x=something' http://localhost:8080/foobar  ==> 404
curl -X PUT -d 'x=something' http://localhost:8080/ ==> 500
(TypeError: index() got an unexpected keyword argument 'x')

Reported by (guest)

Comments (9)

  1. Anonymous

    I came across this writing RESTful code based on the RESTresource recipe, and discovered that an "empty PUT" neither got to my code (which was prepared to handle it) nor generated a log entry or an error back to the browser or curl.

  2. Robert Brewer

    This is due to the following block of code inside wsgiserver:

            if read_chunked:
                if not self.decode_chunked():
                cl = environ.get("CONTENT_LENGTH")
                if method in ("POST", "PUT") and cl is None:
                    # No Content-Length header supplied. This will hang
                    # cgi.FieldStorage, since it cannot determine when to
                    # stop reading from the socket.
                    # See
                    self.simple_response("411 Length Required")

    This was added to fix #493, which worked around a bug in Fieldstorage and a limitation of wsgiserver (pre-CP3). Something's wrong with it, however, because you should at least be getting a 411 response.

  3. guest

    Actually, it's working as you suggested:

    curl -X PUT  -i http://localhost:8080/   ==>
    HTTP/1.1 411 Length Required
    Content-Length: 0

    but curl only shows it when using the -include (headers) option. It doesn't show in the cherrypy log, though.

  4. Robert Brewer

    Ah, right. So there's nothing really ''broken'' with wsgiserver, it just isn't doing what you would hope (writing to the CP log). I'm attaching a patch against trunk (3.x) which would allow that; it removes the 411 response in favor of simply ignoring any request body if there's no Content-Length (nor Transfer-Encoding). But I'm not sure if that's too big a change for 2.2.2 or not...

  5. Anonymous

    Good call. I wonder if one day we won't need to rewrite FieldStorage entirely because we have some tricky workarounds.

    Even though I entirely agree with the use of 411 here it seems this should be the decision of the application and not the wsgiserver in the end.

    Anyway, doubt it can be a real issue for a while. Worth keeping in mind though.

  6. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.