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.

In other words, we *don't* use the Request.url.  We use the Response.url.  But if we expose a cross-origin Response.url for a network request that has a same-origin restriction are security restrictions rightfully want us to fail the request.

The current spec (which I'm asking to change) requires us to either poke a hole through that restriction or avoid using the Response.url in that case.  I don't want to do either one of these.  I want to reject which I think is the safest.

-- 
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-342935704