Opened 4 years ago

Last modified 3 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

Description

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.
        """
        pass

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@… 4 years ago.
Patch for the bug.
1148.diff (7.7 KB) - added by tadeck 3 years ago.
DIFF file for ticket #20034
1148.patch (10.6 KB) - added by tadeck 3 years ago.
PATCH file for ticket #20034

Download all attachments as: .zip

Change History (15)

comment:1 Changed 4 years ago by rfkrocktk@…

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

Pull request with patch here: https://github.com/django/django/pull/898

Changed 4 years ago by rfkrocktk@…

Patch for the bug.

comment:2 Changed 4 years ago by rfkrocktk@…

Here's a workaround I came up with by adapting the Django code in a custom handler: http://stackoverflow.com/a/15377990/128967

comment:3 Changed 4 years ago by rfkrocktk@…

Has patch: set
Type: UncategorizedNew feature

comment:4 Changed 4 years ago by Jacob

Triage Stage: UnreviewedAccepted

comment:5 Changed 4 years ago by Aymeric Augustin

Component: Core (Other)HTTP handling

comment:6 Changed 3 years ago by tadeck

Needs documentation: set
Needs tests: set

Patch looks okay, but needs tests and documentation.

comment:7 Changed 3 years ago by tadeck

Owner: changed from nobody to tadeck
Status: newassigned

Changed 3 years ago by tadeck

Attachment: 1148.diff added

DIFF file for ticket #20034

Changed 3 years ago by tadeck

Attachment: 1148.patch added

PATCH file for ticket #20034

comment:8 Changed 3 years ago by tadeck

Needs documentation: unset
Needs tests: unset
Version: 1.5master

Ready for review.

comment:9 Changed 3 years ago by Ilkka Hakkari

Triage Stage: AcceptedReady for checkin

I went thru https://github.com/django/django/pull/1148 and to me it looks nice.

comment:10 Changed 3 years ago by tadeck

Cc: tadeck added
Easy pickings: unset
Owner: tadeck deleted
Status: assignednew

(deassigned, waiting for someone to merge pull request)

comment:11 Changed 3 years ago by Tim Graham

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

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 3 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