Closed Bug 1399568 Opened 8 years ago Closed 7 years ago

wss fails first connect attempt but works after page reload

Categories

(Core :: Networking: WebSockets, defect, P3)

55 Branch
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: mondain, Unassigned)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170816210634 Steps to reproduce: 1. Open https://webrtc.red5.org/live/broadcast.jsp?host=webrtc.red5.org 2. Enter a "Stream Name" in the form, such as "aaa" 3. Click "Start Broadcast" Step three displays this error in the browser console: Firefox can’t establish a connection to the server at wss://webrtc.red5.org:8083/live?id=aaa 4. Refresh / reload the page 5. Enter a "Stream Name" in the form, such as "bbb" 6. Click "Start Broadcast" 7. Success! Details on the https and wss transports - Server runs in JDK 1.8 Protocol: TLSv1.2 Ciphers in-use: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA Lastly, Chrome and Safari Tech Preview work perfectly the first time and each additional time. Actual results: First attempt fails and refreshing the page allows the second attempt to work Expected results: Firefox should connect and proceed with the publishing process
Component: Untriaged → Networking: WebSockets
Product: Firefox → Core
Michal, can you take a look?
Flags: needinfo?(michal.novotny)
Priority: -- → P2
Whiteboard: [necko-triaged]
I cannot reproduce it with release 56 or nightly 58. Please provide a log, see https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Using_aboutnetworking. Log following modules timestamp,sync,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,nsWebSocket:5
Flags: needinfo?(michal.novotny)
Priority: P2 → P3
We're still seeing wss issues even in the latest releases on linux 61.0.1, win 61.0.1 & 61.0.2, and mac 62. Any new progress or confirmation outside our own testing group?
This is the http logging with the following modules timestamp,sync,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,nsWebSocket:5 https://drive.google.com/open?id=1HSqh21fvtV5MoZvPKHeUNgp9NIpcEwAD This is a txt file of the console output on Firefox https://drive.google.com/open?id=1psYYv7R8L-qsToOkEjrLwrs0eJKgzU7y (In reply to Michal Novotny (:michal) from comment #2) > I cannot reproduce it with release 56 or nightly 58. Please provide a log, > see > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/ > HTTP_logging#Using_aboutnetworking. Log following modules > timestamp,sync,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5, > nsWebSocket:5
This may not be a bug in firefox, but I think firefox could handle the situation better. I've submitted an issue report to the underlying I/O library maintainers and here is a link for further details: https://issues.apache.org/jira/browse/DIRMINA-1094 I've included pcap files for both scenarios.
I've created a scaled down demo which can demonstrate the issue which only occurs in Firefox, primarily tested and verified by me on macOS with Firefix 62. Here's the gist: 1. The issue requires using an SSL certificate, thus its a wss issue. 2. The issue does not occur when websocket.onopen is not utilized. 3. When websocket.onopen is used in the page, with cache enabled or disabled (didn't matter) the wss connection will fail ever-other-time following a repeatable pattern. I will attach the test page and can bring up the test server, should any Firefox engineer be interested in fixing this problem.
Attached file index.html
To enjoy a success on a regular refresh/reload, remove the socket.onopen section.
There may be an issue with the way FireFox handles errant websocket connections in conjunction with ssl (wss), but for the time being we're closing in on a work-around for our application.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: