W3C home > Mailing lists > Public > uri@w3.org > August 2009

Re: [hybi] [Uri-review] ws: and wss: schemes

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
Message-ID: <20090820005933.GA14005@shareable.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

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:52 UTC