Opened 7 years ago

Closed 2 years ago

#9054 closed Bug (fixed)

request.raw_post_data is empty for multipart/related posts

Reported by: gruffudd 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 7 years ago.
Temporary fix
9054-modpython-workaround.diff (1.2 KB) - added by chris chamberlin 7 years ago.
partial hack for mod_python handler

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by gruffudd

Temporary fix

comment:1 Changed 7 years ago by gruffudd

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 7 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 7 years ago by chris chamberlin

partial hack for mod_python handler

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

  • Triage Stage changed from Unreviewed to Accepted

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

comment:6 Changed 7 years ago by Uninen

  • Cc ville@… added

This is possibly related to #3211.

comment:7 Changed 6 years ago by peterbe

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 5 years ago by ramiro

  • Needs tests set
  • Patch needs improvement set

Needs tests and patch most surely needs updating.

comment:9 Changed 4 years ago by lukeplant

  • Severity set to Normal
  • Type set to Bug

comment:10 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:11 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:12 Changed 2 years ago by senko

  • Owner changed from nobody to senko
  • Status changed from new to assigned

comment:13 Changed 2 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 2 years ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

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