Ticket #650 (defect)
Opened 2 years ago
Last modified 2 years ago
PUT request with empty body/params ignored
Status: closed (fixed)
| Reported by: | cb@netalyst.com (guest) | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.2.2 |
| Component: | CherryPy code | Keywords: | |
| Cc: |
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')
Attachments
Change History
01/31/07 17:59:33: Modified by cb@netalyst.com
01/31/07 18:44:06: Modified by fumanchu
This is due to the following block of code inside wsgiserver:
if read_chunked: if not self.decode_chunked(): return else: 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 http://www.cherrypy.org/ticket/493. self.simple_response("411 Length Required") return
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.
01/31/07 18:47:46: Modified by fumanchu
Test added in [1607].
By the way, the quick workaround is to always send a Content-Length (even if zero) with POST and PUT requests.
01/31/07 22:13:41: Modified by 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.
02/01/07 00:16:58: Modified by fumanchu
- owner changed from rdelon to fumanchu.
- status changed from new to assigned.
- milestone set to 2.2.2.
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...
02/01/07 00:17:37: Modified by fumanchu
- attachment putnobody.patch added.
trunk patch to allow PUT, etc. with no body
02/01/07 02:43:20: Modified by lawouach
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.
02/08/07 12:27:06: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
Applied in [1616] to trunk. This should be backported to 2.x.
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.