Closed Bug 1928600 Opened 1 year ago Closed 1 year ago

spacedock.info - "Secure connection failed" when accessing the page

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Platform:
Desktop
Windows 10
Type:
defect

Tracking

(firefox-esr115 unaffected, firefox-esr128 disabled, firefox132 wontfix, firefox133 disabled, firefox134 fixed, firefox135 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- disabled
firefox132 --- wontfix
firefox133 --- disabled
firefox134 --- fixed
firefox135 --- fixed

People

(Reporter: rbucata, Unassigned)

References

(Regression,
URL
)

Details

(Keywords: regression, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:site-broken
configuration:general
affects:all
branch:release
diagnosis-team:networking

Environment:
Operating system: Windows 10
Firefox version: Firefox 132.0

Steps to reproduce:

  1. Navigate to: https://spacedock.info
  2. Observe

Expected Behavior:
The page loads

Actual Behavior::
"Secure connection failed" error

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in firefox-nightly, and firefox-release
  • Does not reproduce in chrome
  • Changing the ETP settings sometimes does not show the error, but the page still fails to load

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

status-firefox132: --- → affected
status-firefox134: --- → affected

Environment:
Operating system: Fedora WS 41
Firefox version: Firefox 132.0

Steps to reproduce:

Navigate to: https://spacedock.info
Observe

Expected Behavior:
The page loads

Actual Behavior::
"Secure connection failed" error

(Fedora 40 with FF 131 unaffected)

Severity: -- → S2
User Story: (updated)
Keywords: webcompat:needs-diagnosis
Priority: -- → P3

The server seems to reset the connection upon receiving SETTINGS_NO_RFC7540_PRIORITIES
This is ultimately a server bug, but I just checked, and it seems Chrome doesn't send SETTINGS_NO_RFC7540_PRIORITIES at all, even though it's using the priority header.
This issue may be bypassed by setting the network.http.http2.send_NO_RFC7540_PRI pref to false in about:config.
This pref is also in the featureManifest if we decide we want to turn it off on without doing a dot release.

Keywords: regression
Regressed by: 1915134

Setting Fx133 and Fx134 to disabled since the pref from comment 2 was set to disabled via Bug 1930122

status-firefox132: affected → wontfix
status-firefox133: affected → disabled
status-firefox134: affected → disabled
status-firefox-esr128: unaffected → affected

Setting 128esr to disabled since the pref from comment 2 was set to disabled via Bug 1930122

status-firefox-esr128: affected → disabled
Depends on: 1930122

Fixed apparently by bug 1930122; works on Nightly on windows and linux for me now.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Set release status flags based on info from the regressing bug 1915134

status-firefox135: --- → affected
You need to log in before you can comment on or make changes to this bug.