1937386 - Schemeless HTTPS-First causes redirect error

Status: RESOLVED FIXED

(Core :: DOM: Security, defect)

Description

[Alexander]

Attachment: firefox133.png

Steps to reproduce:

I enter the address old-dos.ru in the address bar of my browser.
No HTTP or HTTPS prefixes, just "old-dos.ru" in the address bar - this is important.

Actual results:

I administer a website designed for older computers. Accordingly, it does not use HTTPS and it is configured to redirect all requests to HTTPS to HTTP. But instead of correctly redirecting to the site, I get the following error:
"The page isn't redirecting properly"
and so on.
(Redirect loop.)
In other browsers (both old and new - Chrome, Opera, Edge...) the redirect is correct.
In the older Firefox 115 everything is OK too.
Judging by the Network tab in the Inspect window (see screenshot) the site itself responds correctly - the browser requests https://old-dos.ru, gets a 301 response and a new location http://old-dos.ru, but for unknown reasons it requests https://old-dos.ru several times again.
If you enter the full address into the address bar, i.e. http://old-dos.ru or https://old-dos.ru, everything is OK.
This happens only when entering the address old-dos.ru without the HTTP or HTTPS prefix.

Expected results:

The site is expected to open correctly (and normal redirection from HTTPS to HTTP)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alexander]

By the way, similar behavior is observed on other sites that have redirection from HTTPS to HTTP, for example:
dgmag.in
old-web.com
For example, when entering an address in the address bar:
http://dgmag.in - OK
https://dgmag.in - OK (normal redirection)
dgmag.in - not OK

Comment 3

[Kershaw Chang [:kershaw]]

I was unable to reproduce the issue on the nightly build but could reproduce it on the release version. To investigate further, I ran mozregression and discovered that enabling HTTPS-first mode resolves the redirect loop.

10:50.31 INFO: Running autoland build built on 2024-06-25 17:13:28.467000, revision e774888e
/private/var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmp4ed5k7x0/Firefox Nightly.app: replacing existing signature
11:07.01 WARNING: codesign verification failed for /private/var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmp4ed5k7x0/Firefox Nightly.app, re-signing...
/private/var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmp4ed5k7x0/Firefox Nightly.app: replacing existing signature
11:07.39 INFO: Launching /private/var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmp4ed5k7x0/Firefox Nightly.app/Contents/MacOS/firefox
11:07.39 INFO: Application command: /private/var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmp4ed5k7x0/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/ls/95n5m4bj3dv_glk_q345dp8r0000gn/T/tmpoiktpl6x.mozrunner
11:07.40 INFO: application_buildid: 20240621194536
11:07.40 INFO: application_changeset: e774888e32290c3a371f6164be3d90769b8ea845
11:07.40 INFO: application_name: Firefox
11:07.40 INFO: application_repository: https://hg.mozilla.org/integration/autoland
11:07.40 INFO: application_version: 129.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
11:16.83 INFO: Narrowed integration regression window from [55009dbc, 630819c9] (3 builds) to [e774888e, 630819c9] (2 builds) (~1 steps left)
11:16.83 INFO: No more integration revisions, bisection finished.
11:16.83 INFO: Last good revision: e774888e32290c3a371f6164be3d90769b8ea845
11:16.83 INFO: First bad revision: 630819c98ef6bdc758d1b4a3e85a257961decafa
11:16.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e774888e32290c3a371f6164be3d90769b8ea845&tochange=630819c98ef6bdc758d1b4a3e85a257961decafa

Given that this behavior is associated with HTTPS-first mode, I'll update the component to DOM:Security.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Based on comment #3, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:maltejur, since you are the author of the changes in the range, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit BugBot documentation.

Comment 5

[Malte Jürgens [:maltejur]]

I can reproduce this problem, and can confirm that it is related to HTTPS-First. It only happens in a configuration where schemeless HTTPS-First (dom.security.https_first_schemeless) is enabled, but regular HTTPS-First (dom.security.https_first) is disabled. So it is a problem specific to schemeless HTTPS-First. I suspect it is caused by the "is schemeless" flag on the loadinfo not being cleared on the redirect, which causes us to re-attempt to upgrade continuously. And because just schemeless HTTPS-First is enabled, the regular HTTPS-First loop detection is disabled, as we don't expect that subsequent loads are upgraded. I think the fix for this should be relatively straight forward, by just clearing the schemeless flag correctly on redirects.

Comment 6

[Alexander]

BTW, this bug is also present in Firefox 134.0b10 (32-bit).

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 8

[Frederik Braun [:freddy]]

(In reply to Alexander from comment #6)

BTW, this bug is also present in Firefox 134.0b10 (32-bit).

Thanks. I think we will fix it in a future release, maybe by shipping HTTPS-First and therefore disabling updates specific to address-bar loads.

Comment 9

[Malte Jürgens [:maltejur]]

Attachment: Bug 1937386 - Clear schemeless loadinfo flag on redirect r?freddyb!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3661b5a8c4fb
Clear schemeless loadinfo flag on redirect r=freddyb,necko-reviewers,valentin

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/3661b5a8c4fb

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:maltejur, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Malte Jürgens [:maltejur]]

Attachment: Bug 1937386 - Clear schemeless loadinfo flag on redirect r?freddyb!

Original Revision: https://phabricator.services.mozilla.com/D233481

Comment 14

[Malte Jürgens [:maltejur]]

Ugh, I didn't notice we only flipped this pref in 129 (Bug 1905694) after landing the changes in 120 (Bug 1812192). So there is nothing to uplift for ESR 128. Sorry about the confusion and not setting the regressor properly from the beginning.

Comment 15

[Alexander]

status-firefox135: affected → wontfix

But why? Is the bug not serious enough?

Comment 16

[Frederik Braun [:freddy]]

Our default mode is that we fix bugs in current Firefox Nightly first and then consider the risk of grafting the patch into a different branch (beta, release). With this default, we maximize test time. We usually only uplift high-severity patches that affect a lot of users.

While I can see that HTTP support working flawlessly for your web page is if the highest importance, given that you need to support old computers, I am not sure if this bug qualifies as severe enough. Especially, given that old computers often times do not run the latest Firefox anyway?

Comment 17

[Alexander]

Especially, given that old computers often times do not run the latest Firefox anyway?

It's not just about this site, as far as I know there are many sites with HTTPS->HTTP redirects. I gave two more examples above. I think the total number of such sites is in the hundreds.
And not all site visitors use old computers and browsers.

Comment 18

[Alexander]

Anyway, thanks for helping and solving the problem in v136.