Upload handlers provide no way to retrieve previously parsed POST variables

[rfkrocktk@…]

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

[rfkrocktk@…]

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

[rfkrocktk@…]

Patch for the bug.

[rfkrocktk@…]

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

[tadeck]

Patch looks okay, but needs tests and documentation.

[tadeck]

DIFF file for ticket #20034

[tadeck]

PATCH file for ticket #20034

[tadeck]

Ready for review.

[Ilkka Hakkari]

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

[tadeck]

(deassigned, waiting for someone to merge pull request)

[Tim Graham]

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!

[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.