Open andreubotella opened 3 years 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.
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 asb"%0A"
,b"%0D"
andb"%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 theb"%0A"
,b"%0D"
andb"%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 thename
andfilename
parameters are MIMEquoted-string
s, 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"
test1\
test2
test1"; filename=
test2
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 toBody.prototype.formData()
and shouldn't be used for anything else, including new APIs or server implementations. Note that themultipart/form-data
parser in Chrome's implementation of thechrome.webRequest.onListener
extension API has neither of those problems.