Hey Malcolm, Is this still the case? This response was five years ago, why would Django not allow access to PUT and DELETE data?
On Friday, 10 October 2008 11:09:02 UTC+11, Malcolm Tredinnick wrote: > > > On Thu, 2008-10-09 at 14:13 -0700, DaveV wrote: > > Ahh - never mind - I misread the first post. > > > > Still, it would seem helpful if PUT data was processed in a way that > > was more readily accessible, such as a PUT dictionary like the POST or > > GET ones. > > No, because it would be almost always wrong to do so. > > The point is that request.POST is designed for web-browser POST > submission, which means it's going to be data encoded as a form > submission (or a mime-multipart if it contains a file upload). Web > browsers are very restricted beasts. Normal web services encompass a > much broader range of domains and there's no concept of a "common" > format for uploads. You have to look at the content-type and act > appropriately. It could be an XML document (or some subtype), image > data, a word document... anything. The content is described in the HTTP > method. It would be incorrect to attempt to force any of those data > types into dictionaries and not particularly useful for Django to > special case one particular type that will, in practice, actually be > pretty uncommon (machine interacting web services tend to use more > structured formats for sending data than form-encoded, since they're > sending more complex data than simple forms). > > If you're doing REST-based web service stuff -- as opposed to just > interacting with a web browser -- you should ignore request.POST as well > for the same reasons unless you have a very well-understood, restricted > domain that happens to always send form-encoded data. > > Apologies for being unclear in my original post, although you seem to > have worked out my intention. I was trying to say that POST and PUT (and > OPTIONS and DELETE) are treated identically in that all the data is in > raw_post_data, not that there was an attribute for each method. The > latter isn't appropriate for general cases. > > Regards, > Malcolm > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8d44c551-26df-4b1b-9162-7d08c7b54fcf%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
