This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
…or CORS-with-forced-preflight. These should be treated as network failures. This caters for opaque responses being given for XHR, <img crossorigin> etc.
So in http://fetch.spec.whatwg.org/#http-fetch we need to make step 2 more elaborate. 2. If request's skip service worker flag is unset and request's client is not a service worker environment, run these substeps: [HTML] 2.1. Set response to the result of invoking handle a fetch for request. [SW] 2.2. If either /response/'s type is opaque and request's mode is not /no CORS/ or /response/'s type is error, return a network error.
Looks good. Curious if this is a security issue or just about consistency.
I asked horo@ about what opaque intended to mean for img and XHR. Now I understand the background. It seems ideally we should just have the customer specs of the fetch to pass their privilege (XHR cannot read opaque. img can read opaque, etc.) and the fetch returns filtered data based on the privilege than allowing the customer specs to read "internal response".
(In reply to Takeshi Yoshino from comment #3) > It seems ideally we should just have the customer specs of the fetch to pass > their privilege (XHR cannot read opaque. img can read opaque, etc.) and the > fetch returns filtered data based on the privilege than allowing the > customer specs to read "internal response". Isn't that what we are doing here? Only if <img> asks for /no CORS/ can get it get an opaque response from which it needs to obtain an internal response. XMLHttpRequest never asks for /no CORS/ and therefore never gets an opaque response. If that is not what you meant, could you explain what kind of model you would expect?
(In reply to Anne from comment #4) > (In reply to Takeshi Yoshino from comment #3) > > It seems ideally we should just have the customer specs of the fetch to pass > > their privilege (XHR cannot read opaque. img can read opaque, etc.) and the > > fetch returns filtered data based on the privilege than allowing the > > customer specs to read "internal response". > > Isn't that what we are doing here? Only if <img> asks for /no CORS/ can get > it get an opaque response from which it needs to obtain an internal response. Ah, I see. The opaque feature is for hiding data of a response from JS code in SW. To do so, you tried to keep the algorithm between the response concept and the Response object. Instead of adding type==opaque check in the accessors of the Response object, you chose to have the internal response and make it available for <img>, etc. Right? It makes sense.
(In reply to Takeshi Yoshino from comment #5) > Ah, I see. The opaque feature is for hiding data of a response from JS code > in SW. To do so, you tried to keep the algorithm between the response > concept and the Response object. Instead of adding type==opaque check in the s/Response object/Response object simple/
Yeah, that's the idea.
https://github.com/whatwg/fetch/commit/f5ecd97e4956a93f521f179332aa1c2569b092c9