-
Notifications
You must be signed in to change notification settings - Fork 351
Redirect loop handling not discussed #1738
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
Comments
It seems there's two ways we could go about this:
|
Chrome's logic effectively uses both the existing limit and an additional loop detection. The upgrade navigation is still subject to normal redirect limits, but the loop detection can also fail the upgrade much sooner. We found early failures in the upgrade path to be practical. That said, I don't think we should address JS redirects here. The current proposal was intended with only server side redirects in mind. |
@meacer according to @simon-friedberger you all also look at I also realized that it's not quite as simple as I made it out above. In particular if you look at |
We don't have any specific logic for meta redirects. Something like |
I see, I think I got confused by this comment from @simon-friedberger: #1655 (comment). That suggested "redirect-like" behavior would also count. Did someone analyze whether an attacker could use HTTP-redirect loop detection as some kind of side channel? I understand why we'd want to bail out early for an end-user-facing feature so modulo the attacker concern it makes sense to me to define the HTTP-redirect loop detection and use it for HTTPS upgrades. It seems we could build this on top of request's URL list concept? |
What is the issue with the Fetch Standard?
This came up in the context of HTTPS upgrades.
It was discussed in the initial explainer here: https://github.com/dadrian/https-upgrade/blob/main/explainer.md#proposed-behavior-change
@annevk suggested that this should be covered by the 20 redirect limit and asked for a separate issue here.
An example for which we have an issue is a page which redirects after a timeout. (www.bom.gov.au) gets upgraded and then redirects to (http://www.bom.gov.au/akamai/https-redirect.html) which redirects using window.location.replace after 10 seconds. In this case relying on the 20 redirects limit would take over 3 minutes.
The spec does state that requests can be exempt in an "implementation defined way". Chrome seems to have explicit loop detection: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/browser/ssl/https_upgrades_interceptor.cc#519
Of course, the example above also uses a JS based redirect so it may be impossible to define a satisfying solution here.
The text was updated successfully, but these errors were encountered: