Re: [hybi] WebSocket and metadata (Was: BWTP Proposal - Bidirection Web Transfer Protocol)

[Ian Hickson <ian at hixie.ch>]

On Mon, 29 Jun 2009, Jamie Lokier wrote:
> Ian Hickson wrote:
> > I think it's important for this technology to be usable by authors as 
> > soon as browsers support it; in the case of WebSocket this means not 
> > requiring that HTTP servers be upgraded, which can take a long time. 
> > There are still many Web hosts using Apache 1.3, for instance. 
> > WebSocket is intended to be usable by anyone who can open a Unix 
> > socket, which is more or less anyone who can write a CGI script today.
> 
> and
> 
> > WebSocket isn't intended to be related to HTTP at all (though it has 
> > handshake that appears like HTTP and can therefore share a port with 
> > an HTTP server).
> 
> When it shares a port with an HTTP server, you're going to need the HTTP 
> server to accept WebSocket (non-HTTP) traffic and forward it to the WS 
> server, or have the WS server forward HTTP traffic to the HTTP server.

Yes, when you want to reuse a port it's going to be much more work than 
100 lines of code, that's for sure.


> Having the HTTP server forward WebSocket traffic would require upgrading 
> the HTTP server, as WebSocket protocol is not compatible with HTTP.  
> But you said that must not be required, so the only way to do it is 
> forwarding everything through a WebSocket->HTTP proxy.

I'm not sure what you mean. You can use WebSocket without an HTTP server 
just by using a port that isn't taken by an HTTP server, that's simple 
(assuming you control the server). If you want to coexist with a server, 
then you have much more work ahead of you, but WebSocket does support that 
case too, and it shouldn't be that hard to do really (you just have to 
catch the Upgrade request before you send any bytes back, so that the 
WebSocket part of the server can do the handshake).


> It's the port 80 issues - HTTP proxies, filters and spontaneous 
> connection drops - which I think of when I say that a real 
> implementation intended for the larger Web is not trivial.

Well you can still use port 80 (or 443) without an HTTP server if you have 
slightly more control over the server, without having to do much more work 
in the way of coding. I agree that if you want to use the same IP and port 
for both HTTP and WebSocket that it will be a lot more work, but that's 
not required for casual use, you can just use another port. It won't work 
in all situations (e.g. when the user has an over-eager firewall), but 
then that's the cost of being able to write a server in 100 lines of code.


> Whether the tricky things are dealt with in WebSockets itself, or in 
> client applications written by people who only fix what they react to, 
> and thereby provide a low quality / broken experience for everyone 
> behind a low quality web connection.  I favour infrastructure which 
> makes that less likely, rather than more.

I don't understand what you mean here. What would a client have to do? 
What would WebSocket have to do that it doesn't already do?

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