Opened 11 years ago

Last modified 23 hours 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: dev
Severity: Normal Keywords:
Cc: tadeck, Ülgen Sarıkavak 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@… 11 years ago.
Patch for the bug.
1148.diff (7.7 KB ) - added by tadeck 11 years ago.
DIFF file for ticket #20034
1148.patch (10.6 KB ) - added by tadeck 11 years ago.
PATCH file for ticket #20034

Download all attachments as: .zip

Change History (16)

comment:1 by rfkrocktk@…, 11 years ago

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

by rfkrocktk@…, 11 years ago

Patch for the bug.

comment:2 by rfkrocktk@…, 11 years ago

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 by rfkrocktk@…, 11 years ago

Has patch: set
Type: UncategorizedNew feature

comment:4 by Jacob, 11 years ago

Triage Stage: UnreviewedAccepted

comment:5 by Aymeric Augustin, 11 years ago

Component: Core (Other)HTTP handling

comment:6 by tadeck, 11 years ago

Needs documentation: set
Needs tests: set

Patch looks okay, but needs tests and documentation.

comment:7 by tadeck, 11 years ago

Owner: changed from nobody to tadeck
Status: newassigned

by tadeck, 11 years ago

Attachment: 1148.diff added

DIFF file for ticket #20034

by tadeck, 11 years ago

Attachment: 1148.patch added

PATCH file for ticket #20034

comment:8 by tadeck, 11 years ago

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

Ready for review.

comment:9 by Ilkka Hakkari, 11 years ago

Triage Stage: AcceptedReady for checkin

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

comment:10 by tadeck, 11 years ago

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

(deassigned, waiting for someone to merge pull request)

comment:11 by Tim Graham, 11 years ago

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 by rfkrocktk@…, 11 years ago

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.

comment:13 by Ülgen Sarıkavak, 23 hours ago

Cc: Ülgen Sarıkavak added
Note: See TracTickets for help on using tickets.
Back to Top