-
Notifications
You must be signed in to change notification settings - Fork 330
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
Set the HTTPS state to 'modern' for more things #290
Comments
See step 1 of https://fetch.spec.whatwg.org/#websocket-opening-handshake for how "wss" is handled. Although I don't think the HTTPS state of the WebSocket handshake is used for anything. What were you thinking of? Not sure how the rest of this issue relates to Fetch. |
I'm thinking of solving the secure contexts issue I linked to by adding some text around where the Fetch spec has:
In other word saying something along the lines of the following (apologies for the sloppy wording, but you get the idea):
|
I see. @mikewest? |
I think it would be a mistake to allow our definition of secure contexts to seep into Fetch. Fetch knows about network things. It doesn't know about the way that those network things flow into permissions or APIs or anything else. "HTTPS state" on the |
Closing this per @mikewest's comment. Hope that's okay. |
The Fetch spec doesn't mention wss, which presumably should have an HTTPS state of "modern" in general.
More widely though, we should consider whether much of the items where we special case Secure Context would actually be better as a special casing of HTTPS state. That's these cases:
https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
Specifically steps 3, 4, 6 and 7. Explicitly allowing user agents to special case HTTPS state in these cases would resolve, for example:
w3c/webappsec-secure-contexts#26
It would also be more consistent for a document's HTTPS state and Secure Context state to better to match up.
The text was updated successfully, but these errors were encountered: