This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says: A network error is a response whose status is always 0, status message is always the empty byte sequence, header list is aways an empty list, and body is always null. But there is no way to create such a thing. The Response constructor does: If init's status member is not in the range 200 to 599, throw a RangeError. which means there is no way to create a response with status 0.
Perhaps we should offer Response.error() that creates a network error response? Not all responses can be created through script at the moment, but a generic network error might make sense.
I would be fine with that, though it seems like the constructor ought to allow creation of any response, since otherwise you need black magic to explain how these non-constructible responses get created.
Is there a point in creating a response whose mode is CORS or opaque from JavaScript? Also, is there no risk? I think there will always be a need to determine which responses are trusted vs which are created by script. Having said that, we could certainly allow status 0 as well, for network errors.
> Is there a point in creating a response whose mode is CORS or opaque from > JavaScript? Are we self-hosting? This is a serious question; Domenic has been pushing for no magic unexplainable ctors... > Also, is there no risk? I don't know offhand. > I think there will always be a need to determine which responses are trusted vs > which are created by script. Why?
I think e.g. CSP wants to distinguish between custom responses and those actually coming over the network.
Why? So it can avoid blocking the custom responses? But that seems like a matter of allowing creation of custom responses that CSP won't block, not prevention of creation of ones CSP would block.
Wait, I thought you wanted to make the line between custom and non-custom disappear?
I think CSP wants to block custom stuff, similarly to what happens with unsafe-inline / unsafe-eval. Anyway, for cookies and other blocked headers this difference already needs to exist. UAs will have a magic-token constructor. I don't really see a way around that.
> Wait, I thought you wanted to make the line between custom and non-custom > disappear? That was the idea, yes. Comment 6 is consistent with that. > I think CSP wants to block custom stuff That does make things hard, yes. :( > for cookies and other blocked headers this difference already needs to exist. More frowny faces... Alright, let's just allow creation of network error responses for now, since I think that _is_ something useful and safe no matter what.
Late to the party, and thanks for the representation Boris. All I can say at this point is it'd be great to minimize the amount of capabilities reserved for the UA. The mental model should be that if you pass a secret object to the Response constructor, all of a sudden you can set headers that you couldn't before, and you'll get placed into a WeakSet of "trusted" Response instances, and so on.
So the problem with allowing status 0 for creating a network error this way is that it also allows setting a bunch of other fields that would not typically be set for a network error. Having a special Response.error() method for creating network errors would avoid having a bunch of special cases in the general constructor algorithm (trying to prevent setting a body, headers, and such).
https://github.com/whatwg/fetch/commit/7377ff5dac862567f1505c2e901f35d10468079f
Marking as FIXED for now. If we really want to do Response.error() in terms of new Response please file a distinct bug and address comment 11.