Skip to content
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

Closed
jwatt opened this issue Apr 26, 2016 · 5 comments
Closed

Set the HTTPS state to 'modern' for more things #290

jwatt opened this issue Apr 26, 2016 · 5 comments

Comments

@jwatt
Copy link

jwatt commented Apr 26, 2016

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.

@annevk
Copy link
Member

annevk commented Apr 26, 2016

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.

@jwatt
Copy link
Author

jwatt commented Apr 26, 2016

I'm thinking of solving the secure contexts issue I linked to by adding some text around where the Fetch spec has:

If response was retrieved over HTTPS, set its HTTPS state to either "deprecated" or "modern".

In other word saying something along the lines of the following (apologies for the sloppy wording, but you get the idea):

Also set HTTPS state to "modern" if response's URI's host component is or falls within "localhost." [RFC6761] or matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], or the scheme of the URI is one which the user agent considers to be authenticated or has been configured as a trustworthy scheme.

@annevk
Copy link
Member

annevk commented Apr 26, 2016

I see. @mikewest?

@mikewest
Copy link
Member

mikewest commented May 3, 2016

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 response seems like it should only be related to the transport layer.

@annevk
Copy link
Member

annevk commented May 30, 2016

Closing this per @mikewest's comment. Hope that's okay.

@annevk annevk closed this as completed May 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants