Code

Opened 5 years ago

Closed 5 years ago

Last modified 2 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

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.

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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 2 years ago by slacy

  • Cc slacy@… added
  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

comment:3 Changed 2 years ago by slacy

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.