Code

Opened 4 years ago

Closed 3 years ago

#12635 closed New feature (wontfix)

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

Reported by: boxm Owned by: nobody
Component: HTTP handling Version: master
Severity: Normal Keywords: PUT
Cc: lrekucki@…, tomchristie, 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

Attachments (0)

Change History (11)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 3 years ago by lrekucki

  • Cc lrekucki@… added
  • milestone set to 1.3

comment:3 Changed 3 years ago by tomchristie

  • Cc tomchristie added
  • milestone changed from 1.3 to 1.4

Presumably this ought to be Milestone 1.4 now, right?

comment:4 Changed 3 years ago by julien

  • Triage Stage changed from Accepted to 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 Changed 3 years ago by tomchristie

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 Changed 3 years ago by mattmcc

  • Severity set to Normal
  • Type set to New feature

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

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

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

  • Cc asendecka@… added

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

  • Has patch unset

comment:10 Changed 3 years ago by jacob

  • milestone 1.4 deleted

Milestone 1.4 deleted

comment:11 Changed 3 years ago by carljm

  • Resolution set to wontfix
  • Status changed from new to 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.

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.