Closed
Bug 786647
Opened 12 years ago
Closed 12 years ago
WebSocket opens two connections to server, one is empty
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 782704
People
(Reporter: donrhummy, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833
Steps to reproduce:
When I open a WebSocket connection to my server in Firefox, it opens two connections. One of these sends zero data, the other is the "real" connection. Using the same code in Google Chrome only opens one connection.
(I've attached the Java code as a file for testing this, just change the ip address and port for your setup)
HTML CODE
------------
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>WebSocket Test</title></head>
<body>
<script>
try
{
function onOpen(evt){doSend( "hello this is a message" );}
function onClose(evt){websocket.close();}
function onMessage(evt){alert( "Message: " + evt.data );}
function onError(evt){alert( "Error: " + evt );}
function doSend (message){websocket.send( message );}
//PUT IN YOUR OWN LOCAL IP ADDRESS HERE TO GET IT TO WORK
var websocket = new WebSocket( "ws://192.168.1.19:4444/websession" );
websocket.onopen = onOpen;
websocket.onclose = onClose;
websocket.onmessage = onMessage;
websocket.onerror = onError;
}
catch(e)
{
}
</script>
</body>
</html>
Actual results:
Opening one WebSocket in Javascript opened two connections to the server.
Expected results:
One connection should have opened (Which is what occurs in Google Chrome).
Attachment #656426 -
Attachment mime type: text/plain → text/html
|
||
Updated•12 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
|
||
Comment 2•12 years ago
|
||
We issue a 2nd TCP socket connection in case the first one's SYN gets lost in transit. This is fairly standard now in browsers for HTTP (which is bootstrapping websockets). Not sure why Chrome isn't doing it--they are for regular HTTP IIRC
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
(In reply to Jason Duell (:jduell) from comment #2) > We issue a 2nd TCP socket connection in case the first one's SYN gets lost > in transit. This is fairly standard now in browsers for HTTP (which is > bootstrapping websockets). Not sure why Chrome isn't doing it--they are for > regular HTTP IIRC > > *** This bug has been marked as a duplicate of bug 782704 *** Is there anything Firefox does to indicate that one is a "copy" connection? Couldn't firefox at least send a "websocket.close()" command so the server knows it's closing cleanly and not some weird error?
|
|
||
Comment 4•12 years ago
|
||
Well, we don't know which connection is the "copy" until we see which one opened first. Theoretically we could then close the TCP socket for the other connection, although we could also wind up using the socket for regular HTTP purposes if the host/port is the same. Right now we don't special case the websocket logic in our HTTP connection pool code to close just websocket speculative connections. In any case, it's unlikely that closing the socket is the best way to get better response times for your server--the best way is for it to handle accept()ing more than one socket at a time, in a nonblocking manner.
You need to log in
before you can comment on or make changes to this bug.
Description
•