- 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