Define multipart/form-data

[annevk]

Based on Andreu's work at https://github.com/andreubotella/multipart-form-data with mostly editorial changes and some corrections.

This defines a multipart/form-data serializer, which HTML's form submission will use as well, and a parser for formData(), replacing the rough approximation that was there before. In particular:

• A FormData body is serialized when it is extracted and kept as a Blob. This gives the body a length, so Content-Length is set, and means a redirect sends the same bytes again, matching the boundary in the Content-Type header, even if the FormData object has since changed.
• A boundary consists of 27 to 70 ASCII alphanumerics and hyphens and has at least 95 bits of entropy.
• Names are newline normalized and filenames have lone surrogates replaced. In both, LF, CR, and " are escaped as %0A, %0D, and %22. The parser does not reverse this escaping.
• The parser is strict: there cannot be a preamble, header lines have to end in CRLF, header names have to be tokens, and header values cannot contain 0x00 or be folded. Transport padding and the epilogue are ignored.
• How a part's Content-Disposition header is parsed remains an XXX, as that ought to use the same parser as downloads, which is yet to be defined.
• A file part's type is extracted from its Content-Type header as elsewhere in Fetch, defaulting to text/plain, and its lastModified is 0. Other parts are UTF-8 decoded.

Tests: web-platform-tests/wpt#59216

HTML PR: whatwg/html#12992

Fixes whatwg/html#6424 and fixes whatwg/html#7413.

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • Fetch: more multipart/form-data coverage web-platform-tests/wpt#59216
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (not for CORS changes): …
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[zcorpan]

AI re-review at df46626:

• fetch.bs:10285-10293: using extract a MIME type for a part's Content-Type matches no browser:

  • Content-Type: text stays text in all three; the spec gives "".
  • text/html;;x="y" stays raw in all three; the spec gives text/html;x=y.
  • text/html, text/plain gives text/html in Chrome and the raw string in Firefox and Safari TP; the spec gives text/plain.

  Is that intended?

• fetch.bs:10256-10273: nit, body goes from a string to a byte sequence partway through. Maybe use a separate variable.

Possible test additions: a Content-Type with a non-ASCII parameter value (should give ""), and junk after padding on a non-final delimiter (--boundary x\r\n, should fail).