Adding HTML form data handling to core

[StarpTech]

Is your feature request related to a problem? Please describe.

Provide a convenient way to parse and create forms according to https://datatracker.ietf.org/doc/html/rfc7578 and https://xhr.spec.whatwg.org/#interface-formdata

Describe the solution you'd like
Implementation examples:

• https://golang.org/pkg/mime/multipart/#example_NewReader
• https://deno.land/std@0.97.0/mime

Describe alternatives you've considered

Form constructing

• https://github.com/form-data/form-data

Form parsing

• https://github.com/node-formidable/formidable
• https://github.com/mscdex/busboy

Adding new features to the core is a controversial topic. The procedure in #19308 (comment) might help.

Is it hard to be done right?

Yes in a performant way with good API design.

Is it widely used?

Yes, it is.

Does it have a clear spec?

Yes.

Is it likely to become obsolete in the near future?

No.

Does it need optimizations from the core?

Not necessarily.

Will the entire community benefit from it being part of the core?

Yes, it's essential to deal with forms in almost any app.

[Trott]

@bmeck You proposed adding mime to core at some point, didn't you?

[mcollina]

I think the key question to answer is what would add to have this in core. Maintaining things in core is harder than maintaining them in the ecosystem and it adds a burden to a limited set of folks.

[StarpTech]

I think the key question to answer is what would add to have this in core. Maintaining things in core is harder than maintaining them in the ecosystem and it adds a burden to a limited set of folks.

MIME is as stable and important as HTML itself. The implementation should only provide minimal functionality like parsing and stream handling. This allows the community to add additional functionality on top of it. Currently, this is reimplemented every time. I think the maintenance burden is very low until the module is stabilized.

[bmeck]

I did, the PR still is open with a similar pushback.

…

On Sun, Jun 6, 2021, 5:27 AM Dustin Deus ***@***.***> wrote: I think the key question to answer is what would add to have this in core. Maintaining things in core is harder than maintaining them in the ecosystem and it adds a burden to a limited set of folks. MIME is as stable and important as HTML itself. The implementation should only provide minimal functionality like parsing and stream handling. This allows the community to add additional functionality on top of it. Currently, this is reimplemented every time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38943 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJI6BJVOTWE4EPHSXSODTRM5QZANCNFSM46E5CNFA> .

[StarpTech]

Do you mean #21128?

Maybe I miss something but I don't propose mime type handling but MIME multipart parsing.

[bl-ue]

(off-topic: that PR is the oldest one open :)

[MylesBorins]

I'm +1 on continuing to try and get a MIME module into the runtime based on WHATWG spec, that said I think that is a little bit lower level than a full multipart form constructor / parser.

I'm not 100% that we should support the a Form constructor / parser ourselves tbh... although if we were going to explore this I feel like starting in unidici (the next generation http client) might be a good place to focus @nodejs/undici thoughts?

edit: just adding context... I'm not convinced right now that form creation / parsing is a consistent level of abstraction in our platform. We don't offer parsing / creation for other standard data formats (e.g. XML) and while it would be great to have a single implementation for our ecosystem to use, I don't know that the maintenance cost is worth it at the moment. If we do implement fetch it might be worth implementing the FormData constructor from the WHAT WG spec, although we should explore if this can be handled well in userland.

undici-fetch doesn't implement form-data, that might be a good place to explore implementing the spec and figuring out what parts are missing from core to make this easy such as Blob and Mime

[StarpTech]

I'm not convinced right now that form creation / parsing is a consistent level of abstraction in our platform.

Node.js positioned itself as "Node.js designed to build scalable network applications". Sending files from the client to the server is daily business. To explain to a new user that this can't be done easily with Node.js is crazy. I experienced a very bad experience by writing a new abstraction for https://github.com/fastify/fastify-multipart.

I think it can be very valuable to provide a thin module that is only responsible to parse forms. Similar to https://golang.org/pkg/mime/multipart/#example_NewReader

If we can't benefit from the core, it would be also fine to host a module under the Node.js organization as with undici and reference it in the docs.

I think the idea to extend the standard library with regular npm modules very attractive. This is the same strategy we are doing with fastify. House current, high-quality core modules to the community.

Btw: For example, all rust standard modules are crate packages. This can simplifying contribution too.

[Trott]

We talked about this briefly in the TSC meeting today, but didn't get too far without @mcollina and @MylesBorins. However, it seems that it ties into the larger issue of how to decide what goes in core at nodejs/TSC#1041 which is also being discussed by the TSC.

[jasnell]

FWIW, I have implementation of FormData in my todo list for this year as part of the fetch API implementation effort.

(in case the connection is not clear... fetch uses the Body mixin, which includes a method for reading the body of a response as FormData)