- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 20 Aug 2009 01:59:33 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: URI <uri@w3.org>, hybi@ietf.org
Fwiw, I agree with Mark that we should not be shy about using new schemes for new protocols that are not HTTP. Only things which run _over_ HTTP should use be using HTTP URIs, and WebSockets does not run over HTTP... but: Mark Nottingham wrote: > WebSockets is defining a protocol, and so is a very different case. It > is definitely not HTTP. That's correct, WebSockets is not HTTP. However it does begin with an HTTP connection and an HTTP request, to a server which may be serving other HTTP resources on the same port. Quite possibly over port 80, and in the process trip over HTTP proxies. So it's not really the same as telnet, FTP etc. Three notable things for which there is no consensus(*) are: 1. Does the WebSockets really have to use a fresh, new TCP connection for every individual instance of the WebSockets object created on every web page in a browser to the same site? Or could it upgrade an HTTP connection which has already been used for something else? 2. Since it begins with an HTTP request for upgrade to WebSockets, is there any reason for that request not to be to an arbitrary HTTP host+port+path by simply trying the upgrade method on the appropriate HTTP path at the server? 3. If a WebSockets connection cannot be established, clients will(**) fall back to an equivalent (but bulkier/slower) protocol which uses HTTP only. What URI will they use in that case? Do we leave it to individual application/framework designers, or do we suggest a common strategy? * - Although it has been asked if the protocol is a "politically agreed" foregone conclusion (due to an earlier message) and therefore if we are wasting our time with design discussions. ** - As in, even if the spec does not provide this and browsers do not provide it, there will certainly be Javascript WebSockets-emulation modules and corresponding server-sides which do. We can choose to ignore this and leave the mapping from WebSockets URI to HTTP-fallback URI unspecified, or recommend a mapping, or they can simply by the same URI given point 2. -- Jamie
Received on Thursday, 20 August 2009 01:05:30 UTC