Hi,
> That would be really odd imo and confusing as hell if you find
> PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST
If I'm not wrong, only the PUT method can specify POST like
parameters.
> put_data = QueryDict(self.raw_post_data, encoding=your_encoding)
> not really hard if you ask me.
Well, fix is not that simple, since you have to handle the multipart/
form-data case, (which is the default encoding used in test client):
def
get_put_data(request):
content_type =
request.META.get('CONTENT_TYPE')
if
content_type.startswith('multipart'):
parser = MultiPartParser(request.META,
StringIO(request.raw_post_data), [], request.encoding) #nowhere in
docs.djangoproject.com
post, files =
parser.parse()
else:
post =
QueryDict(request.raw_post_data)
return post
I can work with that. My main concern is the lack of clarity in the
documentation. The testing doc asserts that « Client.put() [...] Acts
just like Client.post() except with the PUT request method. » When I
used Client.put in my tests, I was very surprised to find an empty
request.POST. Checked request.PUT ? Nope ! I had to browse a few
threads and bug reports to understand what was happening. Then, I had
to browse django's code to write the method above.
> Stuffing it into POST is a no go, adding an extra PUT/OPTIONS/<whatever
> http verb allows entitity body> is something we don't like either. Given
> that the fix in Client code is a oneliner I think it's not really an issue.
Then, maybe a variable named something like FORM_DATA would be less
error prone? Anyway, I think that discussion should be summarized
somewhere in the documentation, to prevent any further WTF?! effect.
Regards,
Thibault J.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
