[franksalim]

WebSockets have been capable of cross-origin communication since day one. (see: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...) "The |WebSocket-Origin| header is used in the Web Socket handshake. It is sent from the server to the client to confirm the origin of the script that opened the connection. This enables user agents to verify that the server is willing to serve the script that opened the connection."

[daleharvey]

yes but at nowhere in the specification does it say that either the client or server is allowed to modify the origin from the actual origin you are serving / being served from.

This may be part of the specification that I am missing, but it seems to suggest that its using exactly the same origin model as original xhr, which is my complaint

as http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... suggests

"The Web Socket protocol uses the origin model used by Web browsers to restrict which Web pages can contact a Web Socket server when the Web Socket protocol is used from a Web page."

and http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...

"The first three lines in each case are hard-coded" (referring to the origin)

[mbrubeck]

The spec allows the server complete discretion to accept or reject cross-origin requests. Only the origin in the request (sent by the client) is defined in terms of the originating web page; it's left entirely up to the server to decide whether or not to allow requests from any given origin. The spec talks about the server being "willing" to respond to requests from different origins, and explicitly mentions that it may support multiple origins ("This is why the server has to send these strings: to confirm which origins and URLs the server is willing to service").

This is basically the same as the Cross-Origin Resource Sharing spec, another W3C spec supported by some current browsers:

http://www.w3.org/TR/access-control/

> "The first three lines in each case are hard-coded" (referring to the origin)

No, the three hard-coded lines of each handshake part come before the origin headers:

        GET /demo HTTP/1.1
        Upgrade: WebSocket
        Connection: Upgrade
        [...]

        HTTP/1.1 101 Web Socket Protocol Handshake
        Upgrade: WebSocket
        Connection: Upgrade
        [...]

[daleharvey]

the problem isnt the server, http servers right now can serve webpages to any client, its wether the client will allow the connection, as they dont with xhr

from a guess at the fact they specifically say they use the existing same origin policy, they cant, but the confusion is cleared up with a simple test, I will check tomorrow

[mbrubeck]

This is a way for servers to opt in and tell the client to allow cross-domain requests, just like crossdomain.xml or CORS.

I haven't tried it myself with web sockets yet, but I've done some experiments with XHR+CORS (almost the same protocol, except for different names of the response headers) and it does work cross-origin on recent Gecko and WebKit browsers.

UPDATE: Ran a quick test using the current Google Chrome beta for Linux and standalone.py from Google's mod_websocket, and successfully opened a cross-origin WebSocket connection, just as described in the spec. mod_websocket will authorize requests from any origin by default; there's a sample handler included that shows how to reject cross-origin requests on the server.

[daleharvey]

ok cool, if I stand corrected that would be awesome, cheers

[franksalim]

The origin header represents the origin of the script initiating the request. The location is the address of the server. These can be different. By acknowledging the origin of the request, the server explicitly grants access to that origin.

This is similar to the origin model for cross-origin XHRs (http://www.w3.org/TR/access-control/#access-control-allow-or...).