request.raw_post_data is empty for multipart/related posts

[Gruffudd Williams]

core/handlers/wsgi.py : request.raw_post_data is set to empty string if the request self.environ.get('CONTENT_TYPE', ).startswith('multipart').

This is probably ok for multipart/form-data (file upload), but I don't think it is correct for all multipart subtypes, specifically multipart/related, in which message parts should not be considered individually but rather as parts of an aggregate whole : ​http://en.wikipedia.org/wiki/MIME#Related

request.raw_post_data was set correctly in 0.97 but not in 1.0.

A specific example is posting a SOAP/ebXML multipart/related message.

[Gruffudd Williams]

Temporary fix

[chris chamberlin]

The mod_python handler has this same bug.

Another way this bug manifests itself: If I access the raw_post_data attribute first, the POST dict will be empty, even for multipart/form-data. As it stands, you can get your data either in POST or raw_post_data, but not both. Access to both is useful; I wrote middleware to mirror certain POST requests to another location, but it triggers this bug.

My inexpert assessment is that this bug results from changing django.http.HttpRequest.parse_file_upload() to take a file-like object (so it can read chunks), instead of taking the entire request content from raw_post_data as it was done pre-1.0.

An upload handler might help with a workaround?

[chris chamberlin]

partial hack for mod_python handler

[chris chamberlin]

The patch attached just above seems to make it safe to peek at raw_post_data before the POST dict is generated, regardless of what the content-type is. It doesn't entirely fix the issue; you still can't access the attributes in reverse order; after you get POST, raw_post_data will be empty.

[mristroph]

I just applied Chris' patch and it works as described. Thanks, Chris! I had same problem with the POST QueryDict being empty in views after accessing the raw_post_data in a decorator.

[Eric Holscher]

Marking as accepted since it has been reported by multiple people.

[Ville Säävuori]

This is possibly related to #3211.

[Peter Bengtsson]

For what it's worth, I suffered too until I applied the wsgi.py patch and then I was able to have multipart/related SOAP posts posted to my app.

[Ramiro Morales]

Needs tests and patch most surely needs updating.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[senko]

The bug as described in description isn't present anymore, as http.request.HttpRequest._load_post_and_files checks for multipart/form-data explicitly.

Added a test proving the bug isn't there, pull is at: ​https://github.com/django/django/pull/1086

This doesn't address the related issue mentioned by Chris where you can't use both body (raw_post_data previously) and POST. My understanding from the code comments is that it's intentional, to avoid duplication of (potentially big) data in the memory (see comment in tests/requests/tests.py test_body_after_POST_multipart_form_data).

[Aymeric Augustin <aymeric.augustin@…>]

In 566e284c565a9ea95d81756c6b1f94dfa63fc61b:

Added test for multipart, non form-data POST.

Closes #9054. The bug itself is no longer present.