Re: [whatwg/fetch] consider failing same-origin fetch requests that get a cross-origin cors Response synthesized by a service worker (#629)

> That seems rather dangerous if the implementation is indeed still making authority decisions based on the request URL rather than the response concept. It would mean that certain headers normally not exposed through CORS might inadvertently end up being exposed.

Its exactly our universal CORS checking which caught this problem.  Doing what the spec currently says requires poking holes through these security checks.  I have a real problem with doing this.

Also, I would appreciate you addressing my other point that this:

```js
evt.respondWith(fetch(crossOriginURL, { mode: 'cors' }));
```

And this:

```js
evt.respondWith(async function() {
  let corsResponse = await fetch(crossOriginURL, { mode: 'cors' });
  let syntheticResponse = new Response(corsResponse.body);
  return syntheticResponse;
}());
```

Are no longer equivalent.  They used to be when we originally allowed CORS responses to bypass the same-origin Response, but stopped being the same when we chose to expose Response.url.

Also, please address the concern about `self.origin` being a different origin from `self.location` is extremely unusual ergonomics and currently unprecedented for non-local URLs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/629#issuecomment-342933814