Hi Mark, Sadly Malcolm is no longer with us<https://www.djangoproject.com/weblog/2013/sep/16/announcing-malcolm-tredinnick-memorial-prize/> .
There is a thread here<https://groups.google.com/forum/#!msg/django-developers/s8OZ9yNh-8c/yWeY138TpFEJ>for dealing with request parsing which - if it makes it into core - would deal with customisable handling of content types on POST, PUT and other HTTP methods. If you're interested in following this up, that thread would be the place to discuss things. All the best, Tom On Sunday, 1 December 2013 05:38:00 UTC, Mark Brown wrote: > > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/928cbe64-f0de-470e-bace-ff53db326227%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
