-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Value for the crossorigin attribute that makes anon requests same-origin #2614
Comments
We should first decide on #2557 really. |
True, but only if it results in |
Another solution would be to allow I can't think of any real-world scenario where this wouldn't do what the website wanted it to do. |
These 2 requests are quite different: the initial request for both (which is to a same origin URL) will be credentialed in the first case and non-credentialed in the second. Making them match doesn't make sense, and will result in correctness issues. |
In WICG/credentiallessness#3, @slightlyoff noted that it would be quite nice to be able to strip credentials from particular outgoing |
I think it's fine to discuss here. The original issue was more pressing when However, a generic "don't send credentials for this request" attribute/value still seems like a good idea to me.
|
I think adding
I don't see a lot of point in |
To 1, both Your suggestions for 2 and 3 seem reasonable to me as well. Regarding (Note, though, that I'm not sure what the priority of any of this actually is. It doesn't seem like a lot of effort, given that we already have the ductwork in place for things like |
It currently isn't possible to make same-origin no-credentials requests for things that use the
crossorigin
attribute.Notably, this means you can't
<link rel="preload">
afetch()
or script module (unless you make the fetch/script send credentials).A
crossorigin
attribute that changes same-origin behaviour is a bit weird, so maybe there needs to be some sort offetchoptions
attribute on everything that currently usescrossorigin
.+@yoavweiss @igrigorik
The text was updated successfully, but these errors were encountered: