Opened 9 years ago

Closed 5 years ago

#9054 closed Bug (fixed)

request.raw_post_data is empty for multipart/related posts

Reported by: Gruffudd Williams Owned by: senko
Component: HTTP handling Version: 1.0
Severity: Normal Keywords: multipart
Cc: ville@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no


core/handlers/ : 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 :

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.

Attachments (2) (684 bytes) - added by Gruffudd Williams 9 years ago.
Temporary fix
9054-modpython-workaround.diff (1.2 KB) - added by chris chamberlin 9 years ago.
partial hack for mod_python handler

Download all attachments as: .zip

Change History (16)

Changed 9 years ago by Gruffudd Williams

Attachment: added

Temporary fix

comment:1 Changed 9 years ago by Gruffudd Williams

Has patch: set

comment:2 Changed 9 years ago by 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?

Changed 9 years ago by chris chamberlin

partial hack for mod_python handler

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by Eric Holscher

Triage Stage: UnreviewedAccepted

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

comment:6 Changed 9 years ago by Ville Säävuori

Cc: ville@… added

This is possibly related to #3211.

comment:7 Changed 8 years ago by Peter Bengtsson

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

comment:8 Changed 7 years ago by Ramiro Morales

Needs tests: set
Patch needs improvement: set

Needs tests and patch most surely needs updating.

comment:9 Changed 7 years ago by Luke Plant

Severity: Normal
Type: Bug

comment:10 Changed 6 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:11 Changed 6 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:12 Changed 5 years ago by senko

Owner: changed from nobody to senko
Status: newassigned

comment:13 Changed 5 years ago by 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:

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/ test_body_after_POST_multipart_form_data).

comment:14 Changed 5 years ago by Aymeric Augustin <aymeric.augustin@…>

Resolution: fixed
Status: assignedclosed

In 566e284c565a9ea95d81756c6b1f94dfa63fc61b:

Added test for multipart, non form-data POST.

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

Note: See TracTickets for help on using tickets.
Back to Top