[whatwg] WebSockets: Should we decide on protocol before deciding on features?

[Frode Børli]

I think we should agree on which features that WebSockets need to
provide before deciding on a protocol or method of achieving the
goals.

Basically I want these features from WebSockets:

1. The server side script that generated the page can at any later
time raise any event on the client side.
2. The client side script can at any time raise any event on the
server side (meaning inside the script that initially generated the
page).
3. It must work trough existing Internet infrastructure, including
strict firewalls and proxies.
4. It should also be possible to open extra websockets to other
scripts - possibly trough the XMLHttpRequest object.

The above requirements implies that any standard URL can deliver a web
socket (since the web socket piggybacks with the original page
response).

Today requirement 1 can partly be achieved by never completing the
transfer of the HTML-document: whenever the server wants to raise an
event on the client side it appends
"<script>eventhandler(data)</script>" and still does not close the
transfer. Main problem here is that the onload event is never fired...

Number 2 can be achieved by using XMLHttpRequest - but this starts
another script instance on the server for each event raised from the
client, and that is inefficient.

Since the communication is directly to the script that generated the
page, we by default have an URL scheme and all virtual hosting
problems are solved. Also there is no need for cookies or other
authentication schemes to be sure which page the server is talking to.

(imagine the customer having two separate browser windows, both trying
to talk to the same chat server - it brings in a lot of problems that
are not solved by simple cookies).

Number 3 requires that we use port 80 and 443, or that all restrictive
firewalls in the world is reconfigured to open extra ports as well.

Number 4 is implied since 1 and 2 requires the websocket to piggyback
the original response. An AJAX request is basically a page request to
an URL - so a websocket should be able to piggyback it. Also security
restrictions defined for XHR should apply for WebSockets.


I do not care how this is achieved - but as a busy programmer I do not
want to spend hours researching how to implement this. Everything I
need should be provided by HTML 5 compliant browsers and the
webserver/cgi (e.g. Apache/PHP) interface.