-
Notifications
You must be signed in to change notification settings - Fork 336
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
Next steps for HTTPS state #1062
Comments
If I look at how https://fetch.spec.whatwg.org/#concept-http-network-fetch sets it, what really matters is the scheme. If the scheme is not "https", it's equal to "none". Otherwise it could be "deprecated" or "modern". It doesn't seem to account at all for |
OK. So where does that leave us? Should we remove HTTPS state entirely, or no? |
Yeah, I think it can be removed in favor of scheme checks. That's all that remains once you remove "deprecated". As "deprecated" means the scheme is "https", the browser did get a response and accepted the TLS connection, but the browser also judges the TLS connection to be of poor quality. |
Great, OK. So concretely, the CORP check and hyperlink auditing should use a straight-up scheme check. And in the future we can consider changing them to URL's trustworthiness, or secure context checks, as appropriate. |
Yup! |
Part of whatwg/fetch#1062.
Part of whatwg/fetch#1062. Also sets the new-ish fields on environments.
Part of whatwg/fetch#1062.
Part of whatwg/fetch#1062. Also sets the new-ish fields on environments.
I guess everything got merged, yay! |
Part of whatwg/fetch#1062.
HTTPS state causes issues with the secure context definition, as discussed in whatwg/html#4930 (comment). I've checked with folks on the Chrome side, and we no longer need the "deprecated" HTTPS state, so we can fix that issue. I'm willing to work on helping remove it.
However, I need some guidance. Can we remove the "HTTPS state" concept entirely? I'm not sure. The usage sites I've found are:
All other references to HTTPS state in HTML and Fetch appear to be plumbing from responses to new environment settings objects.
If we can't remove it, then: should we just keep the infrastructure as-is, and remove the "deprecated" state? Or maybe we should go further and rename things to make a bit more sense, e.g. change it to a "securely delivered" boolean? Are there other simplifications we could make?
The text was updated successfully, but these errors were encountered: