Opened 13 years ago

Closed 11 years ago

#12635 closed New feature (wontfix)

Process HTTP PUT into request.FILES and request.PUT as done for POST

Reported by: Malcolm Box Owned by: nobody
Component: HTTP handling Version: dev
Severity: Normal Keywords: PUT
Cc: lrekucki@…, Tom Christie, asendecka@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


On a PUT request, Django should populate request.PUT and request.FILES in
the same way as for POST requests. FILES will be initialised if the content
is multipart, and the PUT dictionary will have key/value pairs if the
uploaded content included url-encoded form entries.

At the moment request.FILES is not populated, and request.PUT does not exist.

See discussion here

Change History (11)

comment:1 Changed 13 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

comment:2 Changed 12 years ago by Łukasz Rekucki

Cc: lrekucki@… added
milestone: 1.3

comment:3 Changed 12 years ago by Tom Christie

Cc: Tom Christie added
milestone: 1.31.4

Presumably this ought to be Milestone 1.4 now, right?

comment:4 Changed 12 years ago by Julien Phalip

Triage Stage: AcceptedDesign decision needed

In this thread, Malcolm Tredinnick explains why the current behaviour is by design:

He argues that request.raw_post_data should be used for handling any data coming through REST calls.

Moving as DDN for now.

comment:5 Changed 12 years ago by Tom Christie

See also this proposal, which addresses the issue, albeit in a much broader way...!topic/django-developers/4c4xT3ULNLk

comment:6 Changed 12 years ago by Matt McClanahan

Severity: Normal
Type: New feature

comment:7 Changed 12 years ago by Aleksandra Sendecka <asendecka@…>

Easy pickings: unset
Has patch: set
UI/UX: unset

comment:8 Changed 12 years ago by Aleksandra Sendecka <asendecka@…>

Cc: asendecka@… added

comment:9 Changed 12 years ago by Aleksandra Sendecka <asendecka@…>

Has patch: unset

comment:10 Changed 11 years ago by Jacob

milestone: 1.4

Milestone 1.4 deleted

comment:11 Changed 11 years ago by Carl Meyer

Resolution: wontfix
Status: newclosed

Closing this wontfix based on Malcolm's reasoning in the above-linked thread. request.POST is a special case for form-urlencoded and multipart/form-data content types. This special case makes sense for POST, since browsers submit HTML forms using those content types. But browsers do not PUT (and aren't likely to start), and web services are just as likely (or more likely) to use other content types (e.g. JSON, XML), so it doesn't make sense to special-case form-urlencoded for verbs that aren't used by browsers to submit forms. request.raw_post_data (an unfortunate name, since it's just the request body content, not POST-specific at all) can be accessed directly and parsed as appropriate for the application, according to the content type.

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