Filenames with spaces are always reported as `None` by multipart upload facilities

[Chas Emerick]

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.

[Anton Bachin]

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?

[Calascibetta Romain]

I can take a look at the end of the next week 👍.

[Calascibetta Romain]

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.

[Chas Emerick]

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

[Calascibetta Romain]

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.

[Chas Emerick]

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

[Anton Bachin]

@cemerick It should be fixed now in Dream master, which is using multipart_form 0.4.0. If not, please do comment and we can reopen this issue.