You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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...
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?
The text was updated successfully, but these errors were encountered: