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

HTTPS Upgrades #1654

Open
carlosjoan91 opened this issue May 11, 2023 · 2 comments
Open

HTTPS Upgrades #1654

carlosjoan91 opened this issue May 11, 2023 · 2 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@carlosjoan91
Copy link
Contributor

https://github.com/dadrian/https-upgrade/blob/main/explainer.md proposes a change where eligible (top level frame, GET) HTTP navigation requests are upgraded to HTTPS, and fallback to the original HTTP URL if the fetch over HTTPS fails. This prevents users from making any unnecessary insecure connections since HTTPS will always be used for sites that support it.

This change requires modifying the fetch standard by:

  • Adding an “HTTPS Upgrading” algorithm that defines which types of requests should be upgraded.
  • Adding a “Fallback” algorithm that defines how a failed upgrade should be handled.
  • Adding a new step to Main Fetch (after the existing step 5) that optionally runs the “HTTPS Upgrading” algorithm on the request.
  • Adding a new step to HTTP Fetch that optionally runs the “Fallback” algorithm.
@carlosjoan91 carlosjoan91 added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels May 11, 2023
@carlosjoan91
Copy link
Contributor Author

I'll create a tentative PR of how this change could look in a bit.

@christhompson
Copy link

One question that came up when we were working on this proposal was how to define the "upgrade" and "fallback" steps. In Chrome, these are implemented as internal redirects similar to how HSTS works. There appears to be some desire to codify this fact for HSTS (see #1426 ), so maybe we'd want to do the same here. For now, we erred on the side of being a bit vague as it isn't yet clear to us whether different user agents would implement it in the same manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

2 participants