Opened 3 years ago

Last modified 2 years ago

#20034 new New feature

Upload handlers provide no way to retrieve previously parsed POST variables

Reported by: rfkrocktk@… Owned by:
Component: HTTP handling Version: master
Severity: Normal Keywords:
Cc: tadeck Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


In a custom Django upload handler like the one here, it is impossible to get other POST variables sent along with the multipart request until the handler has completed the upload entirely. Often, it'd be nice to be able to grab the variables as they're parsed to do something with them. Essentially, a method should be added to django.core.files.uploadhandler.FileUploadHandler called something like "variable_complete" which would provide the name and content type of each non-file variable passed with the multipart request:

class FileUploadHandler:

    # ...
    def variable_complete(self, variable_name, variable_value):
        Called after a POST variable has been successfully parsed from the multipart request.

This would save me the trouble of manually having to parse the multipart request myself in "handle_raw_input".

Attachments (3)

0001-Modified-upload-handler-API-to-be-able-to-invoke-cal.patch (1.9 KB) - added by rfkrocktk@… 3 years ago.
Patch for the bug.
1148.diff (7.7 KB) - added by tadeck 2 years ago.
DIFF file for ticket #20034
1148.patch (10.6 KB) - added by tadeck 2 years ago.
PATCH file for ticket #20034

Download all attachments as: .zip

Change History (15)

comment:1 Changed 3 years ago by rfkrocktk@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Pull request with patch here:

Changed 3 years ago by rfkrocktk@…

Patch for the bug.

comment:2 Changed 3 years ago by rfkrocktk@…

Here's a workaround I came up with by adapting the Django code in a custom handler:

comment:3 Changed 3 years ago by rfkrocktk@…

  • Has patch set
  • Type changed from Uncategorized to New feature

comment:4 Changed 3 years ago by jacob

  • Triage Stage changed from Unreviewed to Accepted

comment:5 Changed 3 years ago by aaugustin

  • Component changed from Core (Other) to HTTP handling

comment:6 Changed 2 years ago by tadeck

  • Needs documentation set
  • Needs tests set

Patch looks okay, but needs tests and documentation.

comment:7 Changed 2 years ago by tadeck

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

Changed 2 years ago by tadeck

DIFF file for ticket #20034

Changed 2 years ago by tadeck

PATCH file for ticket #20034

comment:8 Changed 2 years ago by tadeck

  • Needs documentation unset
  • Needs tests unset
  • Version changed from 1.5 to master

Ready for review.

comment:9 Changed 2 years ago by derega

  • Triage Stage changed from Accepted to Ready for checkin

I went thru and to me it looks nice.

comment:10 Changed 2 years ago by tadeck

  • Cc tadeck added
  • Easy pickings unset
  • Owner tadeck deleted
  • Status changed from assigned to new

(deassigned, waiting for someone to merge pull request)

comment:11 Changed 2 years ago by timo

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

Patch needs to be updated to apply cleanly to master and reflect the fact that it would go in 1.7 instead of 1.6. It should also be listed as a minor feature in the release notes. Finally, it would be helpful to include some explanation in the documentation of why this hook would be used. It's not clear from the ticket what the use case for this is which is why I think it was stuck in "RFC" status for so long. Thanks!

comment:12 Changed 2 years ago by rfkrocktk@…

The use case is a special one, but it's still relevant to certain people. In multipart uploads, if a certain field has an incorrect value, it may be of some use to stop the entire file transfer before the data is transferred. For example, given this upload:

Field: authentication-ticket
Value: 1021012021012012

Field: filedata
Value: <binary data>

If the authentication-ticket field was wrong, why transfer a 3.0GB file across the wire? You're wasting bandwidth, disk I/O, and more importantly, client time if you have to wait for 3.0GB to transfer before seeing that you have an incorrect value.

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