[Django] #20034: Upload handlers provide no way to retrieve previously parsed POST variables
Django
-------------------------------+--------------------
Reporter: rfkrocktk@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+--------------------
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".
--
Ticket URL: <https://code.djangoproject.com/ticket/20034>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 1.5
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by rfkrocktk@…):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Pull request with patch here: https://github.com/django/django/pull/898
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:1>
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 1.5
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 1 | UI/UX: 0
Comment (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
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:2>
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: 1.5
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by rfkrocktk@…):
* has_patch: 0 => 1
* type: Uncategorized => New feature
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:3>
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 1 | UI/UX: 0
Changes (by jacob):
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:4>
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 1 | UI/UX: 0
Changes (by aaugustin):
* component: Core (Other) => HTTP handling
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:5>
Django
Reporter: rfkrocktk@… | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by tadeck):
* needs_docs: 0 => 1
* needs_tests: 0 => 1
Comment:
Patch looks okay, but needs tests and documentation.
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:6>
Django
Reporter: rfkrocktk@… | Owner: tadeck
Type: New feature | Status: assigned
Component: HTTP handling | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 1 | UI/UX: 0
Changes (by tadeck):
* owner: nobody => tadeck
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:7>
Django
Reporter: rfkrocktk@… | Owner: tadeck
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Easy pickings: 1 | UI/UX: 0
Changes (by tadeck):
* needs_docs: 1 => 0
* version: 1.5 => master
* needs_tests: 1 => 0
Comment:
Ready for review.
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:8>
Django
Reporter: rfkrocktk@… | Owner: tadeck
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
Easy pickings: 1 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by derega):
* stage: Accepted => Ready for checkin
Comment:
I went thru https://github.com/django/django/pull/1148 and to me it looks
nice.
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:9>
Django
Reporter: rfkrocktk@… | Owner:
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Ready for
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by tadeck):
* status: assigned => new
* cc: tadeck (added)
* owner: tadeck =>
* easy: 1 => 0
Comment:
(deassigned, waiting for someone to merge pull request)
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:10>
Django
Reporter: rfkrocktk@… | Owner:
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Changes (by timo):
* needs_better_patch: 0 => 1
* stage: Ready for checkin => Accepted
Comment:
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!
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:11>
Django
Reporter: rfkrocktk@… | Owner:
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:12>
Django
Reporter: rfkrocktk@… | Owner: (none)
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
* cc: Ülgen Sarıkavak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/20034#comment:13>