-
Notifications
You must be signed in to change notification settings - Fork 329
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
Access-Control-Expose-Headers: * can be interpreted in two ways #548
Comments
I didn't realize you can have a header name that is |
It seems that if we want to avoid conflicts we should do something with
per https://tools.ietf.org/html/rfc7230#section-3.2.6. It seems this is a problem for:
but not Access-Control-Allow-Origin (origins cannot be *). @mnot thoughts? Can we decide not to care about a method or header name which is |
That would mean that the mere presence of a header field which name is e.g. |
Right, the question is whether that's acceptable or whether we should find an alternative syntax? And if the latter, what syntax? |
In pursuit of meaningful, easy-to-understand syntax, I'd discourage finding an alternative syntax.
-> Regards, |
See httpwg/http-core#30. |
Idea:
So basically The only scenario where you'd be out of luck is if for requests without credentials you only want to expose or allow a header/method named The only alternative is using @yutakahirano are you okay with the idea? Would be nice to unblock this and get this feature implemented. |
I'd rather leave it as-is; it makes it clear that when it's alone, the wildcard has special meaning (i.e., the # rule isn't applied to it). As per the issue above, we might remove |
#548 (comment) sg |
I'm okay with making * special when it's the single value, but I will change the grammar for now. If field-name indeed changes we'll just fix our grammar at that point. I'll start working on a PR to clarify the behavior as I think that will clarify any outstanding questions better than discussing it here would. |
So while working on the PR I realized what @mnot suggested doesn't work as we need |
Since `*` is a valid header name and method, only count it as a special value for requests without credentials. Fixes #548.
#592 is my newly proposed model. Basically using * never leads to an error as it's a valid value. And if the header takes comma-separated values than it's fine for * to just be one of the values per earlier comment. As mentioned earlier the only limitation is that you cannot solely safelist a header name or method that is |
Relevant Safari bug: https://bugs.webkit.org/show_bug.cgi?id=169194 |
See whatwg/fetch#548 for details and whatwg/fetch#592 for the corresponding change.
Since `*` is a valid header name and method, only count it as a special value for requests without credentials. And no longer differentiate between `*` being a single value or one of many. Tests: web-platform-tests/wpt#7223. Fixes #548.
Since `*` is a valid header name and method, only count it as a special value for requests without credentials. And no longer differentiate between `*` being a single value or one of many. Tests: web-platform-tests/wpt#7223. Fixes #548.
access-control-allow-origin = #field-name / wildcard
where
field-name = token
token = 1*tchar
tchar contains
*
.
It means "*" can be interpreted in two ways.
This sounds like
*
, the symbol should be interpreted in the first way.*
but headerName is not*
, the symbol should be interpreted in the second way.I feel it confusing.
The text was updated successfully, but these errors were encountered: