The original local file name may be supplied as well, either as a
"filename" parameter either of the "content-disposition: form-data"
header or, in the case of multiple files, in a "content-disposition:
file" header of the subpart. The sending application MAY supply a
file name; if the file name of the sender's operating system is not
in US-ASCII, the file name might be approximated, or encoded using
the method of RFC 2231.
Where RFC 2231 defines attributes with * char. And requests uses such
attribute name to send non-ascii file names.
{{{
# requests 1.2.3
>>> requests.post('http://ya.ru', files={'file': (u'файл',
'123')}).request.body
--cb90e5c32429403b99966534716cda56
Content-Disposition: form-data; name="file"; filename="файл"
Content-Type: application/octet-stream
123
--cb90e5c32429403b99966534716cda56--
# requests 2.0
>>> requests.post('http://ya.ru', files={'file': (u'файл',
'123')}).request.body
--40f2f1873ec843598773fe150b4f783a
Content-Disposition: form-data; name="file";
filename*=utf-8''%D1%84%D0%B0%D0%B9%D0%BB
123
--40f2f1873ec843598773fe150b4f783a--
}}}
But Django doesn't recognize such files and puts raw files content in
`request.POST` instead of population `request.FILES`.
--
Ticket URL: <https://code.djangoproject.com/ticket/22971>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Related requests ticket:
https://github.com/kennethreitz/requests/issues/2117
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:1>
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:2>
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/2908
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:3>
Comment (by homm):
Thanks, claudep, it's great!
A want to note, according
rfc5987(http://tools.ietf.org/html/rfc5987#section-4.2) unicode value
should be preferred over ascii.
In this case, the sender provides an ASCII version of the title for
legacy recipients, but also includes an internationalized version for
recipients understanding this specification -- the latter obviously
ought to prefer the new syntax over the old one.
I still don't know is rfc5987 applicable to multipart headers, though.
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:4>
Comment (by claudep):
In the current implementation, the last one always wins. I'm not sure it's
worth complicating the implementation if we even don't know if some user
agents are indeed using this feature (and with the ascii version appearing
after the encoded one).
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:5>
Comment (by ceaess):
RFC # 5987 isn't relevant here as it's about the server sending files to
the client but not the inverse.
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:6>
Comment (by ceaess):
Sent a pull request to add another test and update the RFC#
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:7>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:8>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"b42e5ca058178d67027bf66d37d00ade635b4c26"]:
{{{
#!CommitTicketReference repository=""
revision="b42e5ca058178d67027bf66d37d00ade635b4c26"
Fixed #22971 -- Properly parsed RFC 2388 encoded headers
Thanks homm for the report, Cea Stapleton for patch improvements
and Ian Cordasco, Christian Schmitt and Tim Graham for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22971#comment:9>