--
Ticket URL: <https://code.djangoproject.com/ticket/17955>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => invalid
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:1>
* status: closed => reopened
* resolution: invalid =>
Comment:
Tickets shouldn't be anonymously closed without any explanation.
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:2>
Comment (by ptone):
for reference, this seems to be pointing to section 4.4 of
http://www.ietf.org/rfc/rfc2388.txt
However, looking at the parser and your description, it is not clear how
you are forming your post data exactly.
Is the file data being included encoded into the form data, or as a file?
It seems to me that the issue should be resolved in
parse_boundary_stream, so that the TYPE = FILE is set up properly, as then
on line 167, the 'filename' is retrieved correctly
What would be ideal is if you could create a tests patch - perhaps in
regressiontests/file_uploads/tests.py that demonstrates the failure?
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:3>
Comment (by alexandre@…):
The thing is, I was missing the "name" field of the content-disposition.
It worked smoothly after I added it.
Although I agree it seems there is an issue with section 4.4
What i also think could be nice, is having a warning/error telling you
your POST data were not well formatted, as django drops the data. (Took me
some time to notice, since my code was working with other sites, ie
facebook)
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:4>
* type: Cleanup/optimization => Bug
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:5>
* status: new => closed
* resolution: => invalid
Comment:
According to the [https://tools.ietf.org/html/rfc7578#section-4.2 Section
4.2: "Content-Disposition Header Field for Each Part" in RFC 7578]:
> The Content-Disposition header field **MUST** also contain an additional
parameter of "name";
so data without the `name` parameter are invalid. It's not an issue in
Django but in provided data. I think it's time to close this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:7>
Comment (by Carlton Gibson):
Good spot, yes. The behaviour for request.FILES was clarified in
9e4b1ad33e436e8fe60af756d7e09639ee886ac2
--
Ticket URL: <https://code.djangoproject.com/ticket/17955#comment:8>