Opened 15 years ago

Closed 13 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

Description

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 http://groups.google.com/group/django-users/browse_thread/thread/5e04a8ffeaa36c7?hl=en

Change History (11)

comment:1 by Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Łukasz Rekucki, 14 years ago

Cc: lrekucki@… added
milestone: 1.3

comment:3 by Tom Christie, 14 years ago

Cc: Tom Christie added
milestone: 1.31.4

Presumably this ought to be Milestone 1.4 now, right?

comment:4 by Julien Phalip, 14 years ago

Triage Stage: AcceptedDesign decision needed

In this thread, Malcolm Tredinnick explains why the current behaviour is by design: http://groups.google.com/group/django-developers/browse_thread/thread/771238a95ceb058e/

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 by Tom Christie, 14 years ago

See also this proposal, which addresses the issue, albeit in a much broader way...

https://groups.google.com/forum/#!topic/django-developers/4c4xT3ULNLk

comment:6 by Matt McClanahan, 14 years ago

Severity: Normal
Type: New feature

comment:7 by Aleksandra Sendecka <asendecka@…>, 13 years ago

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

comment:8 by Aleksandra Sendecka <asendecka@…>, 13 years ago

Cc: asendecka@… added

comment:9 by Aleksandra Sendecka <asendecka@…>, 13 years ago

Has patch: unset

comment:10 by Jacob, 13 years ago

milestone: 1.4

Milestone 1.4 deleted

comment:11 by Carl Meyer, 13 years ago

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