Opened 13 years ago

Closed 13 years ago

Last modified 9 years ago

#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


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 Changed 13 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

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

comment:2 Changed 9 years ago by Steve Lacy

Cc: slacy@… added
Easy pickings: unset
Severity: Normal
Type: Uncategorized
UI/UX: unset

comment:3 Changed 9 years ago by Steve Lacy

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

Note: See TracTickets for help on using tickets.
Back to Top