Remove the CORS flag #960
Remove the CORS flag #960
Conversation
As far as I can tell we use "response tainting" for the same thing. This also fixes an issue whereby we checked origin tainting rather than response tainting in main fetch which results in a minor bug when it comes to opaquing A -> B -> A chains.
|
@JuniorHsu interested in reviewing as well? |
| <a>same origin</a> with <var>request</var>'s <a for=request>origin</a>, <var>request</var>'s | ||
| <a for=request>tainted origin flag</a> is unset, and the <i>CORS flag</i> is unset | ||
| <a>same origin</a> with <var>request</var>'s <a for=request>origin</a>, and <var>request</var>'s | ||
| <a for=request>response tainting</a> is "<code>basic</code>" |
There was a problem hiding this comment.
It's likely I'm missing something, but I don't exactly see how this condition changes, could you please explain:
This also fixes an issue whereby we checked origin tainting rather than response tainting in main fetch which results in a minor bug when it comes to opaquing A -> B -> A chains.
From what I can tell, assuming the current URL's origin is same-origin with request's origin, then:
- Whenever tainted origin flag is unset, response tainting is always "basic" here, and
- Whenever tainted origin flag is set, response tainting is not "basic"
There was a problem hiding this comment.
I think you're right. A -> B -> A does set the tainted origin flag. I guess that means this whole change is editorial. I still think it's for the better though.
There was a problem hiding this comment.
I agree, I think favoring response tainting is clearer. Thanks.
|
The change looks good, but I have a few questions for the future direction. At this moment we have two options for "bookkeeping".
Do we have a general preference to one over the other? What do you think about separating such bookkeeping fields from the concept request? To be honest I'm not very comfortable with these fields as I believe they should be part of loader (or fetcher), not the request. |
|
@yutakahirano I think putting this state on some other "object" makes a lot of sense. I suspect this is still a reasonable incremental step towards that though. If you have a design in mind, could you describe that in a new issue? And if you think solving that blocks this PR, please say so. |
Co-Authored-By: Michael[tm] Smith <mike@w3.org>
Thank you. I don't want to block this PR, and I agree that this is a good change. |
As far as I can tell we use "response tainting" for the same thing.
This also fixes an issue whereby we checked origin tainting rather than response tainting in main fetch which results in a minor bug when it comes to opaquing A -> B -> A chains.
Preview | Diff