search

andreubotella / multipart-form-data

A web-spec definition of multipart/form-data and related algorithms.
https://andreubotella.com/multipart-form-data/
3 stars 1 forks source link

Parsing entry names and filenames #1

Open andreubotella opened 3 years ago

andreubotella commented 3 years ago

The HTML spec, as of whatwg/html#6282, specifies that when serializing multipart/form-data payloads, the '\n', '\r' and '\b' characters in names and filenames must be encoded as b"%0A", b"%0D" and b"%22", respectively. This was changed to match Chromium and WebKit's behavior, and Firefox is in the process of implementing this change (Gecko bug 1686765). Note that a '%' character doesn't get replaced by anything, which makes the b"%0A", b"%0D" and b"%22" sequences in the output ambiguous.

Given that, you might expect at least Chromium and WebKit to decode those escapes sequences when parsing multipart/form-data names and filenames. But as it turns out, every implementation leaves those escapes, and any other percent-encodes for that matter, as is.

There is another issue I noticed when parsing names and filenames, and it's related to Firefox's still current behavior when encoding (which will be changed in bug 1686765). Rather than percent-decoding, Gecko instead escaped '"' quotes by prepending a '\\' backslash (without escaping backslashes themselves). Since the value of the name and filename parameters are MIME quoted-strings, it makes sense to support that escape when parsing, but that would conflict with the serialization as currently spec'd.

Furthermore, when combined with other parsing bugs, we have all three implementations successfully parsing the following Content-Disposition header in different ways:

Content-Disposition: form-data; name="test1\"; filename="; filename="test2"

Name Filename
Gecko test1\ test2
Chromium test1"; filename= test2
WebKit test1\ ; filename=

If these behaviors turn out to be required for web compatibility, then it would mean that the multipart/form-data parser we're specifying would have to be specific to Body.prototype.formData() and shouldn't be used for anything else, including new APIs or server implementations. Note that the multipart/form-data parser in Chrome's implementation of the chrome.webRequest.onListener extension API has neither of those problems.

andreubotella commented 1 year ago

In d9f0abb I added an algorithm for parsing names and filenames. This algorithm reflects how the parser should work to be as compatible with the serialization algorithm as possible (see also whatwg/html#7575 for a proposal to make them more compatible).

However, as mentioned in the OP, this doesn't reflect the current behavior in browsers, and the question of whether the parsing algorithm can be changed to the one in this spec without breaking the web remains open.