Closed Bug 1937722 Opened 2 months ago Closed 2 months ago

archive.org - The page does not load

Categories

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

Desktop
Linux

Tracking

(firefox133 affected, firefox134 ?, firefox135 unaffected)

RESOLVED INVALID
Tracking Status
firefox133 --- affected
firefox134 --- ?
firefox135 --- unaffected

People

(Reporter: rbucata, Unassigned)

References

()

Details

(Keywords: regressionwindow-wanted, webcompat:needs-diagnosis, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs][webcompat:sightline])

User Story

platform:linux
impact:site-broken
configuration:general
affects:all
branch:release
diagnosis-team:webcompat

Environment:
Operating system: Linux
Firefox version: Firefox 133.0

Steps to reproduce:

  1. Navigate to: http://archive.org/
  2. Observe

Expected Behavior:
The page loads

Actual Behavior:
Blank page

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in firefox-release
  • Does not reproduce in firefox-nightly, and chrome

Created from https://github.com/webcompat/web-bugs/issues/145292

Since the site is a popular, used site, we have moved the issue so it might benefit from a patch/up-lift in Release.

Since the status is marked as unaffected for nightly and as affected for release, is it unaffected or affected for beta?
For more information, please visit BugBot documentation.

Whiteboard: [webcompat-source:web-bugs] → [webcompat-source:web-bugs][webcompat:sightline]

Would be useful to get a reverse regression range to figure out what in nightly caused this to be fixed.

Severity: -- → S4
User Story: (updated)
Priority: -- → P2

Padlock icon shows Connection is not secure.

https://archive.org/ works as expected.

This is a server issue, and I get the same bad outcome in Firefox release, nightly, epiphany (webkit), and Chrome on my machine.

To actually test this (and get the bad outcome), though, you have to take care to test in a fresh browser profile.

If you've ever visited the secure/https version of archive.org, you'll have a HSTS upgrade-directive cached, and any subsequent visits to http://archive.org/ will be locally redirected (via HSTS) to the HTTPS version of the site, https://archive.org (which works fine). But if you've never visited the secure/https version of archive.org, then the browser dutifully loads the http version of the URL as-instructed, which in this case is currently a broken/blank page.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → INVALID

(In reply to Daniel Holbert [:dholbert] from comment #5)

To actually test this (and get the bad outcome), though, you have to take care to test in a fresh browser profile.

Note: in Chrome, you can test in a fresh profile by using the user-profile-icon just to the left of the 3-dot menu, and choose "open guest profile". When testing in that guest profile, I get the actual-results here -- I land on the insecure http version of this site, which is a blank page.

One more note: for Firefox Nightly, there were probably a range of nightlies [in the version 133-134 range] that might've bypassed this issue by automatically/speculatively trying the https version of the URL during this bug's STR, if dom.security.https_first was enabled (as it has been by-default in Nightly). But bug 1919544 changed behavior there, to honor the user's manually-entered http:// and not try HTTPS in this case anymore. In any case, current release and current Nightly still get ACTUAL RESULTS here, because release has dom.security.https_first turned off, and current Nightly has it enabled but also has the fix for bug 1919544.

You need to log in before you can comment on or make changes to this bug.