processResponseConsumeBody and opaque responses

[annevk]

I noticed today that fetching scripts in HTML uses this and while it currently seemingly ignores the second argument that seems like a bug as the body on which it tries to operate will have been consumed.

However, it might be somewhat surprising we end up revealing the full byte sequence of opaque responses to callers without any kind of ceremony.

Not really sure how to address this other than add some "be careful" words around this.

@noamr @domenic thoughts?

[domenic]

The use of processResponseConsumeBody in script fetching is quite recent and is part of a general slow movement toward updating things to use the new Fetch callbacks. We indeed do not seem to be using it quite correctly.

For the more general question, I agree there's not much to be done here besides adding "be careful" wording. E.g., <img> and stylesheet probably also need access to the raw bytes, at least for some part of the spec. And then they just need to guard any web-developer-exposed access behind the opaqueness.

[noamr]

If the HTML/CSS specs need to support no-cors fetches, then they also need access to the response body...
As long as the bytes are not exposed directly to the web developer, I don't see what's missing and how another warning would add to the current documentation of what opaque responses are about...

[annevk]

I think there's two things that are wrong here:

• https://fetch.spec.whatwg.org/#fetch-finale needs to operate on the internal response, but currently doesn't. That means a bunch of things end up branching incorrectly.
• In https://fetch.spec.whatwg.org/#fetch-elsewhere-fetch we want to point this out to some extent. Although this only concerns "legacy" callers it still seems good to highlight for future reviewers.

#1413 should land first though.

[annevk]

Let's close this in favor of #1511 and #1512.