#9950 closed Uncategorized (invalid)
PUT requests do not have request body handled
Reported by: | ssolon | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 1.0 |
Severity: | Normal | Keywords: | |
Cc: | slacy@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Only POST requests are checked for a request body and have the content handled and placed into request dictionaries.
Writing a REST server needs to respond to PUT requests.
Change History (3)
comment:1 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
Severity: | → Normal |
Type: | → Uncategorized |
UI/UX: | unset |
comment:3 by , 13 years ago
As RESTful APIs become more and more important (alongside the rise of client-side framewarks like Backbone.js, knockout.js, Ember.js, etc.) this issue is quite a hinderance to the adoption of Django.
I think the right solution here is to have some kind of pluggable system (akin to a Middleware, in fact, it even may be one) that detects content types and parses and stuffs the WSGIRequest with the relevant info. Telling clients to parse it themselves is a copout. The input side of HTTP is just as well defined as the output, and the logic can be as simple as "check the input content type and call the right parser".
POST requests that are HTML form submissions are handled automatically, because that has been the traditional (and still most predominant way) Django is used. However, for arbitrary HTTP requests, we cannot do any automatic handling, as the content types could be literally anything at all. So for non-browser cases (which means PUT, DELETE, as well as arbtirary POST requests), you have to access the raw data and deal with it yourself. Django cannot read your mind for the general case and it's really not worth handling the very, very special edge case of a form submission for non-form-based use-cases.
So this is a wontfix, as there's nothing that really can be done (it would only interfere with the code).