Filenames with spaces are always reported as `None` by multipart upload facilities
cemerick opened this issue · 7 comments
When uploading files via multipart form submission, filenames are always reported as None
for any files that have spaces in their name. This can be easily verified in the playground by submitting a file with a space in the filename. e.g. the following request body (as reported by devtools):
-----------------------------11410681503802810592492044004
Content-Disposition: form-data; name="dream.csrf"
ADMQDYZs8zn7Yh8mF27YFJCNq2ggIMub66g13DdY0ks5TSjOt0kj8av4gWzflcSA273JCsPoksybWAcvb0ZcsV4yD6NrbCZMqFJDuey7DRAZ
-----------------------------11410681503802810592492044004
Content-Disposition: form-data; name="files"; filename="a b.txt"
Content-Type: text/plain
1234
-----------------------------11410681503802810592492044004
Content-Disposition: form-data; name="files"; filename="a.txt"
Content-Type: text/plain
1234
-----------------------------11410681503802810592492044004--
Produces this output:
None, 4 bytes
a.txt, 4 bytes
Note that while the playground linked above uses the non-streaming multipart API, the same result obtains when using the streaming API.
I'm guessing the problem lies in the multipart_form
library, but despite spending a little time to verify that with a minimal failure case, I was not able to grok that library's API. So, it seemed like the next best thing to do would be an issue at the "top level" here.
Thanks @cemerick!
I'm guessing the problem lies in the
multipart_form
library, but despite spending a little time to verify that with a minimal failure case, I was not able to grok that library's API. So, it seemed like the next best thing to do would be an issue at the "top level" here.
@dinosaure, are you able to tell (without spending too much time :)) if this is indeed a problem with multipart_form
?
I can take a look at the end of the next week 👍.
From my introspection, multipart_form
does not index contents from filename
but from name
value. In your example, you have two parts which share the same name
. I think the problem is more: how we use multipart_form
than multipart_form
itself (which extracts correctly all values). I will do a look into dream
next week to see where is exactly the problem.
I can't make any hard claims about where the problem lies, but no, I do not believe it is related to there being multiple parts in a form submission. Select and upload just a single file with a name containing spaces to the dream playground; the same failure occurs.
e.g. this:
-----------------------------179816902527686570444059401214
Content-Disposition: form-data; name="dream.csrf"
APtpDmWOr1CKRPm4WglwVfphr_trfXgdDlU20os-hOZt9Apsj9eqxJHZvI-SW0lv2889O70XtjpQ-9bwtuzahA-lnL-rxOUsexvkuswaxkWN
-----------------------------179816902527686570444059401214
Content-Disposition: form-data; name="files"; filename="a b.txt"
Content-Type: text/plain
-----------------------------179816902527686570444059401214--
yields:
None, 0 bytes
Hmmhmm ok that's weird. RFC822 says:
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
Which seems correct for you but RFC5322 says:
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
And it does not includes space character. multipart_form
wants to follow RFC2045 but I go further because I was focus on email - so I followed RFC5322. According the order of RFCs, multipart_form
should back to RFC822 and accepts space indeed. I will propose a pull-request on it and cut a release then so.
Thank you very much for attending to this, @dinosaure. 🙏 I can't verify your fix immediately, but will do so ASAP and report back here. (Simply pinning or vendoring multipart_form doesn't work, since the library's structure has changed since the dream release back in May. I guess I'll have to vendor dream itself until thing percolate through.)