-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Work on standardizing multipart/form-data parsing (for Request.prototype.formData
)
#10
Comments
I agree this is very important. But also the |
Certainly. @lucacasonato had some proposals about this. But they would still involve defining a |
The fetch spec includes APIs for interacting with form submissions. For example, there is the
Request
andResponse
constructors acceptingURLSearchParams
andFormData
objects as the request/response body, which is generally useful and is expected to be part of the common minimum API.However, the fetch spec also defines the
formData()
method of theBody
interface mixin, which is included inRequest
andResponse
. This method parses the HTTP body as a form submission enctype (eitherapplication/x-www-form-urlencoded
ormultipart/form-data
) and returns aFormData
object. Since form submission bodies only generally make sense as requests, and it's rarely useful to parse a request body from an HTTP client, it wouldn't make much sense to include this method as part of the common minimum API – but it is certainly useful for fetch-based HTTP server APIs, as Deno and CFW have.For
multipart/form-data
parsing, however, this method leaves things almost completely unspecified. While there is a formal definition of this format (in RFC7578, which relies on themultipart
definitions in RFC2046), it is in the form of an ABNF grammar rather than a parsing algorithms, and so different implementations differ in how they parse some input.What's more, browsers have not always escaped field names and filenames in
multipart/form-data
payloads in the same way. For example, until last year Firefox escaped double quotes by prepending a backslash, and newlines by turning them into spaces; while Chromium and Webkit used percent-encoding. And while this percent-encoding behavior was added to the HTML spec (whatwg/html#6282), and FIrefox's behavior fixed in turn, no implementation of the parsing that I'm aware of (including Chromium and Webkit!) decode the percent-encoding escapes:For browsers, specifying
multipart/form-data
parsing is not a big priority, since there are not many use cases for them, and theformData()
method has been broken for 8 years or so. But for WinterCG runtimes with a fetch-based HTTP server API, being able to parse form submissions with the existing fetch API is crucial, and being able to accurately parse the form submissions that all browser engines are currently submitting is a large part of that. So this seems like a very interesting issue to tackle as part of the WinterCG project.The text was updated successfully, but these errors were encountered: