-
Notifications
You must be signed in to change notification settings - Fork 21
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
Use a structured header for preflights #45
Comments
I suppose the main inconsistency would be with |
I see. I think it would be best to maintain consistency between both. We can indeed use a token |
There might be a benefit in the future if/when structured fields get their own on-the-wire representation. We should probably migrate these legacy fields to the extent possible as it's a minor win of sorts, but as there's no on-the-wire representation that's different from legacy fields it hasn't been a priority (or observable). |
Filed whatwg/fetch#1216 to use structured fields "upstream". That issue blocks this one for now. |
I think this might be a rare instance where structured headers are not quite the right fit, largely due to it extending an existing design. I do think specifying it as a structured header could work, but it should be with a token value, not a boolean, as only that's fully compatible. |
It could be specified as both, to keep the door open to structuring |
Both token and boolean seems more trouble than it's worth. |
Oh, would a "true" token be incompatible? I was under the impression that it could be a spec-only change. |
I meant having both. :-) I think a ` |
Oh, ha! Got it. |
@martinthomson makes a point in w3ctag/design-reviews#572 (comment):
It's true that we could use a structured field for the new headers. The only downside I could see is inconsistency with other CORS headers. @mikewest what do you think?
The text was updated successfully, but these errors were encountered: