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

[Malcolm Box]

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

[Tom Christie]

Presumably this ought to be Milestone 1.4 now, right?

[Julien Phalip]

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.

[Tom Christie]

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

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

[Jacob]

Milestone 1.4 deleted

[Carl Meyer]

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.