archive.org - The page does not load
Categories
(Web Compatibility :: Site Reports, defect, P2)
Tracking
(firefox133 affected, firefox134 ?, firefox135 unaffected)
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:
- Navigate to: http://archive.org/
- 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
Reporter | ||
Comment 1•2 months ago
|
||
Since the site is a popular, used site, we have moved the issue so it might benefit from a patch/up-lift in Release.
Reporter | ||
Updated•2 months ago
|
Comment 2•2 months ago
|
||
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.
Updated•2 months ago
|
Comment 3•2 months ago
|
||
Would be useful to get a reverse regression range to figure out what in nightly caused this to be fixed.
![]() |
||
Comment 4•2 months ago
|
||
Padlock icon shows Connection is not secure
.
https://archive.org/ works as expected.
Comment 5•2 months ago
•
|
||
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.
Comment 6•2 months ago
•
|
||
(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.
Description
•