feat(formdata/unstable): new module

[BlackAsLight]

This pull request introduces a new package (@std/formdata), offering a way to process FormData content in a streaming manner. It is based off the RFC 7578 spec.

When a website submits a standard HTML form, it is sent using the multipart/form-data content type. Currently, servers must wait until the entire payload has been received before any processing can begin, which often forces them to impose strict size limits and rely on client-side JavaScript to handle larger uploads. This pull request addresses that limitation by enabling servers to process large uploads incrementally, without requiring JavaScript on the client, and even allowing it to be completely disabled.

Example

import { assertEquals } from "jsr:@std/assert";
import { FormDataDecoderStream } from "jsr:@std/formdata";

const request = new Request("https://example.com", {
  method: "POST",
  body: function() {
    const formData = new FormData();
    formData.append("a", "b");
    return formData;
  }()
});

for await (const entry of FormDataDecoderStream.from(request)) {
  assertEquals(entry.name, "a");
  assertEquals(await new Response(entry.value).text(), "b");
}

[tomas-zijdemans]

Sorry, I'm quite inexperienced in deno std.

Looking at YAML parsing in the std it uses SyntaxError for malformed input. So instead of:

if (buffer == undefined) throw new Error("Unexpected EOF");

you could do:

if (buffer == undefined) throw new SyntaxError("Unexpected EOF");

...and so on.

Then, when the caller makes a mistake you could opt for TypeError. So instead of:

if (contentType == undefined) {
    throw new Error("Content-Type header is missing");
}

you could do:

if (contentType == undefined) {
   throw new TypeError("Content-Type header is missing");
}

...and so on

[BlackAsLight]

This is ready to be reviewed btw. The only failing test is the pull request title

[kt3k]

Thanks for the PR and sorry for the delay in review.

I'm not sure if this should be an independent package. Would it make sense to include it under std/http?

[BlackAsLight]

I'm not sure if this should be an independent package. Would it make sense to include it under std/http?

Maybe. I can move it there if everyone thinks that's better

[tomas-zijdemans]

I vote for placing it in http 👍