[whatwg/fetch] Allow strings or byte sequences as bodies? (#1073)

This is several issues in one...

HTML always invokes Fetch with byte sequence request bodies. The two invocations are:

- https://html.spec.whatwg.org/#form-submission-algorithm:concept-request-body
- https://html.spec.whatwg.org/#hyperlink-auditing:concept-request-body

I think we should allow this, instead of requiring HTML or other callers to create new `ReadableStream` instances. Fetch could, very early in the Fetch algorithm, [construct a fixed ReadableStream instance](https://fetch.spec.whatwg.org/#concept-construct-fixed-readablestream).

HTML also has a few places where it wants to supply a string as a response body in a synthetic response:

- https://html.spec.whatwg.org/#the-iframe-element:concept-response-body
- https://html.spec.whatwg.org/#navigating-across-documents:concept-response-body

These are interesting because I know that Blink, at least, has a direct path for javascript: URLs and iframe srcdoc to set the resulting document's value as a string. Bytes never get involved, and the charset defined for the document is ignored. (I don't know if the HTML spec defines the charset of the produced documents very well for those cases...)

I'm not sure what we should do here. Maybe HTML's navigate algorithm should grow a new type of "resource", the string resource, since this seems very specific to that case? Or HTML could UTF-8 encode and created a fixed stream itself. Maybe with a helper defined in Fetch, like "created a fixed string body"?

I can't think of an easy way for Fetch to handle this in general, because we probably want to confine string-bodies to these navigation special cases; certainly any cases that might pass through service workers need to be stream-bodies.

Finally, HTML also treats script response bodies as byte sequences:

- https://html.spec.whatwg.org/#fetching-scripts:concept-response-body and 3 other very similar places.

But this is already covered in https://github.com/whatwg/fetch/issues/661, so we can ignore it for this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1073