Re: [hybi] Apples and Orangutans

[Ian Hickson <[e-mail]>]

On Sun, 12 Apr 2009, Maciej Stachowiak wrote:
> > 
> > WebSocket includes a path (from the ws:// URL), which is intended to 
> > be analogous to the TCP port number.
> 
> I'm not sure the path is a good choice for identifying the type of 
> service available. HTTP has both a path and a type. The path is sent by 
> the client and identifies the specific resource. The type is sent by the 
> server and directs how the resource is to be interpreted. I do not think 
> we can expect, for example, multiple chat services to use the same path 
> format, but there may be multiple chat services which choose to use the 
> same protocol-by-convention over WebSocket. Right now, there doesn't 
> seem to be a good way to give this information to the client, in the 
> same way that any arbitrary URL can tell the client that its contents 
> are to be interpreted as XML or PDF or plain text.

I don't understand why a 16bit integer solves the problem for TCP, but a 
string doesn't solve the problem for WebSocket. They seem exactly 
equivalent to me -- they identify the target of the connection, and by 
convention, the protocol that that target supports.

Why couldn't we exect multiple chat services to use the same path for 
their chat server, in the same way that multiple chat services written on 
TCP use the same port?

There's also plenty of precedent on the Web of including type information 
in the URL -- so much so, in fact, that some people find the path 
(specifically the "extension" part of the "filename" component of the 
path) more reliable than the explicit Content-Type data. There's also 
"well-known paths" like robots.txt, which, while suboptimal from HTTP's 
point of view, seem like they'd fit in well with WebSocket.

It's not really clear to me how we would expose the information in the API 
if we were to use something other than the path. It's not like most 
authors are going to care, or check to see what the remote end thinks it 
is speaking -- they'll connect to their own servers, or to well-known 
remote third-party servers, and just talk the protocol that that endpoint 
supports. The path is convenient in that we already have it and it seems 
like it's exactly where authors would put the distinction (just as they do 
today on the Web -- content negotiation is used far less than just 
different URLs for different types, after all).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'