Closed Bug 1725800 Opened 4 months ago Closed 4 months ago

Don't consider it's a upgrade downgrade loop if the uri path is different


(Core :: Networking, defect, P1)

Firefox 91



93 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- wontfix
firefox91 --- wontfix
firefox92 --- wontfix
firefox93 --- verified


(Reporter: Fanolian+BMO, Assigned: kershaw)


(Regression, )


(Keywords: nightly-community, regression, reproducible, Whiteboard: [necko-triaged])


(2 files)

+++ This bug was initially created as a clone of Bug #1725026 +++

The issue below is similar to bug 1725026 but that does not fix my issue.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Build ID: 20210814094200

Steps to reproduce

  1. Enable HTTPS-Only Mode in all windows. Make sure is true.
  2. Open (a Chinese tech forum)
  3. Click on 討論區, which locates at the end of the top bar which writes "主頁 專題報導 新聞中心 新品快遞 超頻領域 流動數碼 生活娛樂 會員消息 討論區". (See the attached screenshot if you cannot find it.)

Actual result

HTTPS-Only Mode Alert is triggered. Clicking Continue to HTTP Site will load

Expected result

No alert is triggered.


  1. The link at 討論區 points to but the final destination is (with a trailing slash).
  2. Left/Middle/Right click at the link -> Open Link in New YYY all trigger the alert.
  3. Unlike bug 1725026 comment 2, copying -> open a blank new tab -> paste link will also trigger the alert.


  1. Set to false. Or
  2. Disable HTTPS-Only Mode. (it will still reach


Same with bug 1725026, this is regressed by bug 1716069.

Flags: needinfo?(kershaw)
Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1716069
See Also: → 1725026

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 and the server returns a 301 with location
    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 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.

Assignee: nobody → kershaw
Flags: needinfo?(kershaw)
Whiteboard: [necko-triaged]

The previous comment was edited, since I think the root cause of this bug is that we only check if the host in identical in nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop. When a page/server wants to redirect a uri with a different path, it should not be a upgrade and a downgrade loop.

Summary: HTTPS-only mode no longer works as it did before Firefox 91 (Part 2) → Don't consider it's a upgrade downgrade loop if the uri path is different
Pushed by
Also check if the uri path is the same when doing upgrade and downgrade loop check, r=ckerschb
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

The patch landed in nightly and beta is affected.
:kershaw, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kershaw)

I think we can let it ride the train. Thanks.

Flags: needinfo?(kershaw)
Flags: qe-verify+

I was able to reproduce this bug by using the steps from comment 0, on an affected Nightly build (2021-08-14).

The issue is verified as fixed on latest Beta 93.0b7, across platforms: Win 10 x64, macOS 11 and Ubuntu 18.04 x64.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.