feat(http/unstable): FormData Decoder/Encoder Streams

[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 👍

[kt3k]

LGTM!

[KnorpelSenf]

@BlackAsLight is there a reason why you chose to only support streams but not iterators?

[BlackAsLight]

@BlackAsLight is there a reason why you chose to only support streams but not iterators?

The preferred use case is via the .from method which returns a ReadableStream instead of an instance of itself. ReadableStreams are already iterators.

The multipart/form-data media type isn't the same as other file formats as you need information within the headers to correctly decode it. These streaming classes aren't TransformStreams like Tar and Cbor offers but instead meant to be the start or end of a streaming process.

[KnorpelSenf]

I meant that I would want to pass an (async) iterator here without first having to convert it to a stream

[BlackAsLight]

Did you mean this line: https://github.com/denoland/std/pull/6928/changes/BASE..637c16fcb6c6b3058e2f323d474c351248959fe8#diff-9a727642d87d2fe68db223e18e8d935be3dd5a12031a1de01657571e9467a412R21

If so, simply for simplicity. One can do ReadableStream.from to convert an iterator or async iterator to a stream. Even if I changed the type, it would just move it to me wrapping it in a stream instead of you.

Asking for a stream specifically instead of an iterator also means I can take advantage of byob if it is available. Although if I'm being honest, the lack of support for a byob stream to continue being byob through a TransformStream is disappointing.