26735 2014-09-05 13:01:15 +0000 Reject opaque ServiceWorker responses if the original request has a mode of CORS 2014-09-09 11:11:06 +0000 1 1 1 Unclassified WHATWG Fetch unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 jaffathecake annevk mike tyoshino sideshowbarker+fetchspec oldest_to_newest 111061 0 jaffathecake 2014-09-05 13:01:15 +0000 …or CORS-with-forced-preflight. These should be treated as network failures. This caters for opaque responses being given for XHR, <img crossorigin> etc. 111125 1 annevk 2014-09-06 09:47:02 +0000 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. 111234 2 tyoshino 2014-09-09 05:23:25 +0000 Looks good. Curious if this is a security issue or just about consistency. 111237 3 tyoshino 2014-09-09 07:57:21 +0000 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". 111239 4 annevk 2014-09-09 09:02:54 +0000 (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? 111248 5 tyoshino 2014-09-09 09:56:57 +0000 (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. 111249 6 tyoshino 2014-09-09 09:57:56 +0000 (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/ 111251 7 annevk 2014-09-09 10:20:50 +0000 Yeah, that's the idea. 111256 8 annevk 2014-09-09 11:11:06 +0000 https://github.com/whatwg/fetch/commit/f5ecd97e4956a93f521f179332aa1c2569b092c9