search

yrift / jwebsocket

Automatically exported from code.google.com/p/jwebsocket
0 stars 0 forks source link

RFC subprotocol isn't supported and current URL method doesn't work with Firefox 4.0b6 #49

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Use Firefox 4.0b6 and open a WebSocket using URL and custom protocol 
parameters [new WebSocket(url, "mycustomprotocol")].  Also, pass the custom 
protocol in the URL [/;prot=mycustomprotocol].
2. Open the socket.
3. The socket connects to jWebSocket and sends back a handshake that doesn't 
include "mycustomprotocol" support.  jWebSocket connector indicates the default 
subprotocol, instead of that passed in the URL or via the WebSocket constructor.
4. Firefox closes the socket because "mycustomprotocol" support is not 
indicated.

What is the expected output? What do you see instead?

Expected output is that jWebSocket sends back a handshake that indicates 
support for "mycustomprotocol" and the connection is not closed by Firefox.

Note just using the URL doesn't work in Firefox, because the jWebSocket 
connector doesn't seem to pick it up.  This works fine in other browsers 
(Safari, Chrome).

What version of the product are you using? On what operating system?

Latest on Mac OS X.

Please provide any additional information below.

The source code in TCPEngine appears to only use the URL parameter to detect a 
subprotocol.  It should also check the header according to the RFC.  Another 
issue is that the supported protocols must be returned in the response.  In my 
case, I have a custom WebSocketServer.  So ideally, TCPEngine would give all 
the servers a chance to add to the set of supported subprotocols.

Original issue reported on code.google.com by deniswb...@gmail.com on 21 Sep 2010 at 4:18

GoogleCodeExporter commented 8 years ago 
Hi Denis, thanks for your hint. You are right and we will implement the sub 
protocol according to the RFC as soon as possible. I put this request to high 
priority. Alex.

Original comment by fivefeetfurther@gmail.com on 5 Oct 2010 at 1:56

GoogleCodeExporter commented 8 years ago 
Please also refer to http://code.google.com/p/jwebsocket/issues/detail?id=42 
which addresses the same item.

Original comment by fivefeetfurther@gmail.com on 5 Oct 2010 at 1:58

GoogleCodeExporter commented 8 years ago

Original comment by fivefeetfurther@gmail.com on 14 Oct 2010 at 2:39

GoogleCodeExporter commented 8 years ago 
I'll take that, Alex

Original comment by fivefeetfurther@gmail.com on 15 Oct 2010 at 4:15

GoogleCodeExporter commented 8 years ago 
Hi, I updated our JavaScript client, or Java Clients and the TCPEngine to 
properly support the Sec-WebSocket-Protocol header field. Previously we only 
used prot=JSON, CSV or XML as URL argument. From now we do it the right way :-) 
The corresponding values for the sub protocol are “jWebSocket-JSON”, 
“jWebSocket-CSV”, “jWebSocket-XML” and “jWebSocket-Custom”, default 
remains JSON.

Because some old clients still will be in the market I kept the old protocol 
mechanism but marked it as deprecated. Although I carefully checked everything 
this might affect some of your work. If you experience any issues please let me 
know.

2010-10-24 15:46:15,251 DEBUG - TCPEngine: Handshake Request:
GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost:8787
Origin: http://localhost
Sec-WebSocket-Protocol: jWebSocket-Custom
Sec-WebSocket-Key1: 384   k 8 ?598d6` 9S 1
Sec-WebSocket-Key2: S1 a  1664D228  00x

%Ę£Ìxê™
2010-10-24 15:46:15,252 DEBUG - TCPEngine: Parsing initial WebSocket 
handshake...
2010-10-24 15:46:15,324 DEBUG - TCPEngine: Handshake Response:
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Sec-WebSocket-Protocol: jWebSocket-Custom
Connection: Upgrade
Sec-WebSocket-Origin: http://localhost
Sec-WebSocket-Location: ws://localhost:8787/

§U£Ãˆír7≈©œN,¯

Original comment by fivefeetfurther@gmail.com on 24 Oct 2010 at 3:23

GoogleCodeExporter commented 8 years ago 
I successfully ran tests with Chrome 7, Safari 4 and even Firefox 3.6.11 with 
FlashBridge worked perfectly.
Unfortunately Google's SVN currently does not allow me to submit :-( I'll try 
again ASAP.

Original comment by fivefeetfurther@gmail.com on 24 Oct 2010 at 3:30