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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mondain, Unassigned)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
|
2.35 KB,
text/html
|
Details |
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
Updated•8 years ago
|
Component: Untriaged → Networking: WebSockets
Product: Firefox → Core
Comment 1•8 years ago
|
||
Michal, can you take a look?
Flags: needinfo?(michal.novotny)
Priority: -- → P2
Updated•8 years ago
|
Whiteboard: [necko-triaged]
Comment 2•8 years ago
|
||
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.
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.
Description
•