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 , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
Cc: | added |
---|---|
milestone: | → 1.3 |
comment:3 by , 14 years ago
Cc: | added |
---|---|
milestone: | 1.3 → 1.4 |
comment:4 by , 14 years ago
Triage Stage: | Accepted → Design 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 , 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 , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:7 by , 13 years ago
Easy pickings: | unset |
---|---|
Has patch: | set |
UI/UX: | unset |
comment:8 by , 13 years ago
Cc: | added |
---|
comment:9 by , 13 years ago
Has patch: | unset |
---|
comment:11 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
Presumably this ought to be Milestone 1.4 now, right?