1868167 - The page can not be reached due to it not being secured at nih.gov

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[Raul Bucata]

Environment:
Operating system: Android 12
Firefox version: Firefox Nightly 122.0a1 (2015989607-🦎122.0a1-20231203092644🦎)

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate to : http://nih.gov/
2. Observe the result.

Expected Behavior:
The page loads

Actual Behavior:
An error message is thrown

Notes:

• Reproducible regardless of the status of ETP
• Reproducible on the latest build of Firefox Nightly and Release
• Works as expected using Chrome
• Screenshot attached
• Issue found during WebCompat team [Top100] websites testing

Comment 1

[Raul Bucata]

Attachment: Screenshot_3.png

Comment 2

[Raul Bucata]

Verified this issue and still reproduces on Firefox 123 and 125.

Tested with:

Browser / Version: Firefox Release 123.0 (2016003223-🦎123.0-20240212203859🦎)/ Firefox Nightly 125.0a1 (2016005159-🦎125.0a1-20240222103314🦎)/ Firefox Beta 123.0b9 (2016002567-🦎123.0-20240209102425🦎)/ Chrome Mobile Version 121.0.6167.180/
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Comment 3

[Calin Tanase]

It seems to be a redirect problem when trying to access "nih.gov" or "http://nih.gov". On Chrome when accessing "nih.gov" it redirects to "https://www.nih.gov".

Note: Accessing https://www.nih.gov directly, loads the page as expected

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Browsers: Firefox Nightly 125.0a1-20240312214346 / Firefox Release 123.0.1-20240304104836 / Chrome 122.0.6261.64

Comment 4

[Daniel Holbert [:dholbert] (PTO until 2/24)]

This reproduces in Firefox on Desktop as well; it's not Android-specific. I can reproduce it in Firefox 127.0.2 (64-bit) on Ubuntu 22.04, for example.

However, it doesn't reproduce in Nightly anymore, due to our "https-first" project (which makes us jump directly to loading https://www.nih.gov/ using https even if http was entered).

I don't know for sure but I suspect that's how this managed to work in Chrome, too; it looks like they have a similar feature, announced last year in https://blog.chromium.org/2023/08/towards-https-by-default.html

Comment 5

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Looks like the Nightly pref-flip that made this start working was in bug 1719271, which landed on 6/23 (though it's using an IS_NIGHTLY_BUILD check for now; this isn't riding the trains yet).

I'm not sure if there's a bug for preffing this on for release, so I'll just mark it as depending on the metabug with alias https-first-mode as the underlying platform bug for now.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Seems like we know what's going on here.

Comment 7

[Daniel Holbert [:dholbert] (PTO until 2/24)]

There's been a few changes here:
(1) https-first (which had fixed this in Nightly) no longer helps here anymore, as of bug 1919544
(2) ...but this also fails in Chrome nowadays, if I perform the exact same steps and start in the same fresh-user-profile state. (I don't know for sure if that's a change in Chrome's behavior or a change in the site or a change in my testing methodology vs. what I or others were doing previously here.)

To actually test here, it's important to start with a fresh user-profile, because the HTTPS version of the NIH website sends a HSTS header which forces the browser to auto-upgrade any future http URLs to be https. So as soon as you actually visit the https site, then you'll get expected-results from that point onwards (regardless of browser). So that's why you have to start with a fresh user-profile here. In Chrome, the easiest way to do that is to click the "user-profile menu" just to the left of their 3-dot-menu button, and then choose "Open Guest Profile".

Comparing Firefox (135 Nightly and 133 release) and Chrome (133 "dev") on desktop, I get the same results in all three of these experiments:
(A) If I manually type http://nih.gov into the URL bar in a fresh user profile: I get a network error page. (Firefox Nightly/Release give "The connection was reset | The connection to the server was reset while the page was loading"; Chrome gives "This page isn’t working | nih.gov didn’t send any data. | ERR_EMPTY_RESPONSE".
(B) If I click comment 0's link to http://nih.gov in a fresh user profile: I get a network error page (same as described above)
(C) If I type nih.gov (no http/https, i.e. "schemeless") into the URL bar and hit enter: then I get automatically upgraded to https and the page loads just fine. (This makes subsequent explicit http loads work fine too, for HSTS reasons noted above.)

Comment 8

[Daniel Holbert [:dholbert] (PTO until 2/24)]

A bit more nuance, though:

Specifically on Android, though, I do see Chrome and Firefox Nightly unconditionally giving expected-results here -- I don't ever get an error page there (even starting with a fresh user profile).

It looks to me like that's because both Firefox Nightly on Android and Chrome-on-Android unconditionally upgrade http to https and hence get expected results here. I'm guessing that's because both Firefox Nightly and Chrome are failing to distinguish between schemeless and HTTP uris on Android, due to lacking the appropriate logic in their URL bar code to tell whether the user typed in http:// or not and pass that through to the https-first logic. (I suspect that's part of the explanation on Firefox Nightly at least; that's covered in bug 1901120.) That Android behavior is arguably a bug rather than an expected-outcome; if a user goes to the trouble of manually typing out http:// in their URL (which is more-cumbersome-to-do on Android), it's odd for the browser to disregard that. Bug 1919544 has some justifications for why that upgrading is weird/unwanted. So we probably shouldn't be coming at this from a stance of expecting that behavior.

So: I don't think we should really consider this to be a webcompat problem, since (a) the issue seems to really just be a site misconfiguration, (b) all browsers get the same bad-experience from that site misconfiguration on Desktop at this point (at first load), and (c) the issue goes away once you've loaded the https site (or omitted at least once

There is one Firefox-for-Android specific issue here, though -- if you just type "nih.gov" (schemeless) and hit enter, that should technically get upgraded, but it currently fails to do so. That's due to bug 1901120.

So, bottom line:
(1) I'd suggest that we consider the network-error on explicit loads of http://nih.gov/ to be expected-results (since that happens in Chrome/Firefox-on-desktop too).
(2) I'd suggest that we morph this bug to be specifically about what happens when the user simply types nih.gov (schemeless) -- that fails right now, only in Firefox-release-on-Android, and that's a version of bug 1901120.