Has anyone read Hickson's May 2010 draft-hixie-thewebsocketprotocol-76 WebSocket protocol?
Here is the the source of an .htm file:
<html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript">
var socket = new WebSocket('ws://localhost:8181/websession');
socket.onopen = function() {
alert('handshake successfully established. May send data now...');
};
socket.onclose = function() {
alert('connection closed');
};
</script>
</head>
<body>
</body>
</html>
If I have a TCP port listening on 8181, this is the request I get when I load the .htm file above in Chrome:
GET /websession HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost:8181
Origin: null
[\n]
(Where [\n] is CRLF character.)
What should I return to this handshake opener? draft-hixie-thewebsocketprotocol-76 shows:
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample
8jKS'y:G*Co,Wxa-
This response causes socket.onclose to fire though.
Draft 76 renamed the WebSocket- response headers to Sec-WebSocket-, and added some unnecessarily ugly Key header and request body crypto stuff to which the 8jKS'y:G*Co,Wxa- is a response. But that's only the correct response for the example included in the draft; it's no good returning that specific string for any other request. See this post for an explanation of how to implement the new protocol.
In any case, unless you are using the latest development builds, Chrome/Chromium will still be using the old draft 75 protocol (as the request you posted demonstrates), and won't talk to the a server that implements the new protocol. See the Chromium blog for more info. If you need to support old/current Chrome versions you effectively have to implement two WebSocket protocols.
This is always the risk in developing stuff against a protocol that is not yet standardised. You can expect annoying interinoperability until WebSocket is finalised; you may prefer to hold off until then.
(Trying to actually read the spec and work out what exactly has changed amongst the reams of unreadable parsing algorithms, is an exercise in frustration. I have no idea why it is written like this instead of the usual BNF-style specifications RFCs like. It's as if Hixie wrote a parser in C and then wrote an automated tool to turn the code into English. C would have been more readable TBH.)
You might find the wsproxy included in noVNC to be useful as a reference. It transparently supports both WebSockets v75 and v76 clients.
wsproxy is a generic WebSockets to TCP socket proxy. There is both a C and python version of wsproxy included with noVNC.
http://github.com/kanaka/noVNC/tree/master/utils/
Also, just to keep things interesting, the latest (no version yet) draft proposal changes things up again (in particular it changes how things are framed): http://www.whatwg.org/specs/web-socket-protocol/
Related
I am currently using the FLASK developer HTTP server, and I am trying to build a local service (run on localhost) that serves files for a remote visualization website.
Here is the code for the python side
#app.route('/task/<path:path>', methods=['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'CONNECT', 'OPTIONS', 'TRACE', 'PATCH'])
def static_file1(path):
p = "./task/" + path
return flask.send_file(p, conditional=True)
For safari, it just works like a charm.
As this screenshot indicates, flask development http server can serve files partially.
However, it didn't work for firefox for one request but not for the other.
And here are the headers for the first failed request
Successful request header
So I do believe the CORS header (Access-Control-Allow-Origin) is set correctly, otherwise the second request would fail.
Then what did I do incorrectly?
Second part:
It also doesn't work in Chrome, both requests failed, but I found the article below explaining new security features:
https://developer.chrome.com/blog/private-network-access-preflight/#:~:text=%23%20What%20is%20Private%20Network%20Access,to%20make%20private%20network%20requests.
But even with "Access-Control-Allow-Private-Network" set to "true" (See screenshot above), both requests still failed in chrome. And error msg:
Access to XMLHttpRequest at 'http://localhost:10981/task/a5c8616777d000499ff0cd5dbb02c957/datahub.json' from origin 'https://somepublic.website' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
Any suggestion would be helpful!
Thanks!
Update 1:
After enabling ad-hoc SSL context (unsigned certificate) on the flask side, and using https on both localhost and "the public website", and changing the "#allow-insecure-localhost" flag in chrome to true, it works in chrome now. But still doesn't in firefox.
If you check the specification you will see that it is a "Draft Community Group Report" and
This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
The contribute list is made up entirely of people working for Google.
I can't find any mention of it in Firefox's bug tracker.
It looks like this is a highly experimental specification, which Firefox simple doesn't implement.
There doesn't appear to be any way to persuade Firefox to provide access from a secure, public Oritin to an insecure private origin.
I have this problem with compression, and I am not sure if it is a bug. My WebSocket server does not support context takeover, and I am having problems sending messages, but not receiving.
The browser issues a request like this:
GET /socket HTTP/1.1
Host: thirdparty.com
Origin: http://example.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
If the server does not specify any option about context takeover:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Access-Control-Allow-Origin: http://example.com
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Extensions: permessage-deflate
I can read and write the first message, but cannot do subsequent reads or writes, because Chrome expects the server is keeping the context.
So my server provides this answer:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Access-Control-Allow-Origin: http://example.com
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Extensions: permessage-deflate; client_no_context_takeover; server_no_context_takeover
And now I can receive messages without problems, but again, I can only send the first message, the second message fails, and I see an error in Chrome saying that it failed at inflating the frame. I tried to send two identical strings, and I can see how the server is sending twice the same data, but the client fails to decompress it the second time.
So it seems that Chrome accepts the client_no_context_takeover parameter that specify that the client won't use the same compression context for all messages when compressing, but ignores server_no_context_takeover indicates the server won't use the same context.
Is this a bug in Chrome? I am not clear about if I can send options back that have not been offered/requested by the client.
Is there any other option I can use to disable the client context takeover?
UPDATE:
In WebSocketPerMessageDeflate.cpp in the Chromium source code, I can see:
if (clientNoContextTakeover != parameters.end()) {
if (!clientNoContextTakeover->value.isNull()) {
m_failureReason = "Received invalid client_no_context_takeover parameter";
return false;
}
mode = WebSocketDeflater::DoNotTakeOverContext;
++numProcessedParameters;
}
But also:
if (serverNoContextTakeover != parameters.end()) {
if (!serverNoContextTakeover->value.isNull()) {
m_failureReason = "Received invalid server_no_context_takeover parameter";
return false;
}
++numProcessedParameters;
}
In the first snippet, it is setting the "mode" variable, but in the second one is not doing nothing, so it seems it is basically ignoring the parameter.
Cheers.
A server must send a server_no_context_takeover parameter in a response only if the client requested the "no context takeover". In essence, the server acknowledges the client's request.
If a server decides to do "no context takeover" for sending on it's own (without the client having requested it), that's fine. In this case, no parameter is sent by the server.
A deflate sender can always on it's own drop compression context and/or reduce compression window size. There is no need to tell the receiver. The deflate wire format has enough information for the receiver to cope with that.
Here is how configuration and handshake looks with Crossbar.io.
I finally found the problem.
https://datatracker.ietf.org/doc/html/draft-ietf-hybi-permessage-compression-17#section-8.2.3
8.2.3.4. Using a DEFLATE Block with BFINAL Set to 1
Going through the examples in the draft I found my server was sending slightly different payloads. Turned out that the problem was the BFINAL, I need to set it to 0 by adding a 0 byte at the end.
Now it works.
I'm currently trying to develop a simple Flash game which talks to a node.js server.
My question is this:
How might I go about making a server which differentiates web requests from game requests?
Here are the details of what I've done:
Previously, I used the net and static modules to handle requests from the game client and the browser, respectively.
TwoServers.js
// Web server
var file = new staticModule.Server('./public');
http.createServer(function(req, res){
req.addListener('end', function(){
file.serve(req, res, function(err, result){
// do something
});
});
}).listen(port1, "127.0.0.1");
// Game Server
var server = net.createServer(function(socket)
{
// handle messages to/from Flash client
socket.setEncoding('utf8');
socket.write('foo');
socket.on('data', onMessageReceived);
});
server.listen(port2, "127.0.0.1");
I'd like to do the above with just an Express server listening in on a single port, but I'm not sure how to go about doing that.
Here's what I'm thinking it might look like (doesn't actually work):
OneServer.js
var app = express();
app.configure(function()
{
// ...
app.use('/',express.static(path.join(__dirname, 'public'))); // The static server
});
app.get('/', function(req, res) // This is incorrect (expects http requests)
{
// Handle messages to/from Flash client
var socket = req.connection;
socket.setEncoding('utf8');
socket.write('foo');
socket.on('data', onMessageReceived);
});
app.listen(app.get('port')); // Listen in on a single port
But I'd like to be able to differentiate from web page requests and requests from the game.
Note: Actionscript's XMLSocket makes TCP requests, so using app.get('/') is incorrect for two reasons:
When Flash writes to the socket, it isn't using the http protocol, so app.get('/') will not be fired when the game tries to connect.
Since I don't have access to correct the net.Socket object, I cannot expect to be reading or writing from/to the correct socket. Instead, I'll be reading/writing from/to the socket associated with the web page requests.
Any help on this would be much appreciated (especially if I'm reasoning about this the wrong way).
When a TCP connection is opened to a given port, the server (Node + Express) has no way of telling who made that connection (whether it's a browser or your custom client).
Therefore, your custom client must speak HTTP if it wishes to communicate with the Express server sitting on port 80. Otherwise, the data you send over a freshly opened socket (in your custom protocol) will just look like garbage to Express, and it will close the connection.
However, this doesn't mean you can't get a TCP stream to speak a custom protocol over – you just have to speak HTTP first and ask to switch protocols. HTTP provides a mechanism exactly to accomplish this (the Upgrade header), and in fact it is how WebSockets are implemented.
When your Flash client first opens a TCP connection to your server, it should send: (note line breaks MUST be sent as CRLF characters, aka \r\n)
GET /gamesocket HTTP/1.1
Upgrade: x-my-custom-protocol/1.0
Host: example.com
Cache-Control: no-cache
The value of Upgrade is your choice, Host MUST be sent for all HTTP requests, and the Cache-Control header ensures no intermediate proxies service this request. Notice the blank line, which indicates the request is complete.
The server responds:
HTTP/1.1 101 Switching Protocols
Upgrade: x-my-custom-protocol/1.0
Connection: Upgrade
Again, a blank line indicates the headers are complete, and after that final CRLF, you are now free to send any data you like in any format over the TCP connection.
To implement the server side of this:
app.get('/gamesocket', function(req, res) {
if (req.get('Upgrade') == 'x-my-custom-protocol/1.0') {
res.writeHead(101, { Upgrade: req.get('Upgrade'), Connection: 'Upgrade' });
// `req.connection` is the raw net.Socket object
req.connection.removeAllListeners(); // make sure Express doesn't listen to the data anymore... we've got it from here!
// now you can do whatever with the socket
req.connection.setEncoding('utf8');
req.connection.write('foo');
req.connection.on('data', onMessageReceived);
} else res.send(400); // bad request
});
Of course, remember that TCP is not a message-based protocol, it only provides a stream, and thus the data events of a Socket can either fragment a single logical message into multiple events or even include several logical messages in a single event. Be prepared to manually buffer data.
Your other option here is to use socket.io, which implements a WebSockets server plus its own protocol on top of the WebSockets protocol. The WebSockets protocol is message-based. It mostly works just like I've outlined here, and then after HTTP negotiation adds a message framing layer on top of the TCP connection so that the application doesn't have to worry about the data stream. (Using WebSockets also opens the possibility of connecting to your server from a HTML page if necessary.)
There is a Flash socket.io client available.
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/
I am trying to implement a websockets server in java but I am having trouble understanding the version of websocket protocol does google chrome implements. In this blog post the Chromium team mentions that they have implemented version 76 of the websockets protocol which should have the following handshake request (copied from official version 76 spec (section 1.2)):
GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Origin: http://example.com
^n:ds[4U
where as the handshake request I am getting from google chrome(8.0.552.237) is :
GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost:8082
Origin: http://localhost:8081
Sec-WebSocket-Key1: g3 I 9w F : Kt 3?u784C-0 99 5z
Sec-WebSocket-Key2: 4 S5l&Y4m]11+4 032s Ecfl
ïÿÁëƒ^
Can somebody please explain me why is there a discrepancy between googles version and the official spec. And what would be the right format of the response for google's version.
PS: does anybody has any estimate by when the websockets protocol would be finalized ?
Chrome currently implements draft-hixie-thewebsocketprotocol-76 which is also known as draft-ietf-hybi-thewebsocketprotocol-03. The protocol and specs are now being published by the IETF HyBi working group thus the 03 numbering is actually more correct and the next versions of the spec will continue that numbering (but most people still call it v76).
The handshake you are getting from Chrome-8.0.552 does match the spec. The differences are because the ordering of the headers can vary and the keys will have different values for every new connection and the host, origin, path, and protocol values depend on how the Javascript invokes the connection and also depend on the URL of the invoking page.
The response will look something like this (although not exactly because the response is generated based on the client handshake):
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample
8jKS'y:G*Co,Wxa-
I've been following the HyBi working group and there is no estimate for when the protocol will be finalized. However, a new draft (04) has already been published trying to address security concerns of the browser vendors. A (05) version will likely be published in the next few weeks. The browser vendors probably won't implement 04 (because there are still significant areas of low consensus). If most of the browser vendors adopt 05 and there are no additional security concerns I suspect that the final version of the protocol will not change much from there.
It's important to note however, that the browser API for WebSockets is likely not going to be affected by changes in the protocol.