Bugzilla

A short summary for this issue:
 1. The case in bug 1725026: The load is triggered by user gesture and we do HTTPS upgrade because of HTTPS-only mode.
    I think the patch in bug 1725026 is reasonable, since we do user gesture check for the first load. However, that patch doesn't fix this issue completely.
    
 2. The case in this bug: A link points to `https://www.hkepc.com/forum` and the server returns `301` points to `http://www.hkepc.com/forum/`. We do HTTPS upgrade to `https://www.hkepc.com/forum/` because of HTTPS-only mode.
  This is not a upgrade and downgrade loop, since the uri path is actually different, despite that we only check host name in `nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop`. Note that the patch in bug 1725026, since the redirection chain is not empty. I think we should revert the change in bug 1716069 by moving user gesture check before redirection chain.

3. The case in bug 1716069: this is actually an upgrade and downgrade loop.
  If we revert the changes in bug  1716069, `nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop` will return false and we'll reach redirection limit (`NS_ERROR_REDIRECT_LOOP`)in the end. Note that not just HTTPS RR leads to `NS_ERROR_REDIRECT_LOOP`, but also HTTPS-only mode. The difference is that HTTP-only mode shows a warning page and offers a user an option to continue to `http` site, but HTTPS RR doesn't.

In conclusion, I'll revert the changes done in bug 1716069, since this should fix bug 1725026 and this one. I'll also try to make the behavior of HTTPS RR similar to HTTPS-only mode: when we reach the redirection limit, we should fallback to `http`.

A short summary for this issue:
 1. The case in bug 1725026: The load is triggered by user gesture and we do HTTPS upgrade because of HTTPS-only mode.
    I think the patch in bug 1725026 is reasonable, since we do user gesture check for the first load.
    
 2. The case in this bug: A link points to `https://www.hkepc.com/forum` and the server returns a `301` with location `http://www.hkepc.com/forum/`. 
  This is not a upgrade and downgrade loop, since the uri path is actually different. The problem here is that we only check [host name](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/dom/security/nsHTTPSOnlyUtils.cpp#289) in `nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop`. To fix this,  I think we should also check the path here.

3. The case in bug 1716069: this is actually an upgrade and downgrade loop.
  If we revert the changes in bug  1716069, `nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop` will return false and we'll reach redirection limit (`NS_ERROR_REDIRECT_LOOP`)in the end. Note that not just HTTPS RR leads to `NS_ERROR_REDIRECT_LOOP`, but also HTTPS-only mode.