Re: websocket HTTP response parsing

On Sun, 6 Jul 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > > But in that case the response to the upgrade request would still 
> > > come from the HTTP server (I think), in which case it may not be 
> > > possible to generate the exact octet sequence you specced...
> > 
> > Well, where it comes from depends on how the server is written. Since 
> > the server has to be upgraded to handle WebSockets at all, it doesn't 
> > seem unreasonable for it to be upgraded in the particular way required 
> > by the spec today.
> 
> As far as I can tell, it depends on specifics of the server 
> implementation. I can easily imagine cases where it's the HTTP server 
> that replies to the upgrade request, and control to the new server 
> component passes only afterwards. In that case it could be hard to 
> produce the specified byte sequence.

Yes, it may require careful work when the servers are updated.


> Also, did you consider the impact of intermediates in the request path?

You mean, like proxies? Sure, the spec defines how to handle those.

(Incidentally, I can't claim credit for designing the Web Sockets 
protocol. It's based on ideas from mcarter.)


> > > > > And also, why not require an empty reason phrase (which would 
> > > > > get rid of having plain text messages in English hardwired into 
> > > > > the protocol)?
> > > >
> > > > Given that the handshake blob is basically opaque, what's wrong 
> > > > with having hardwired? The previous version had the handshake be 
> > > > just "Hello" "Welcome", which is just as hardwired to English.
> > >
> > > Well, it can't be HTTP and opaque at the same time, unless I'm 
> > > missing something.
> > > 
> > > If it really is opaque, just make it simple, instead of adding 
> > > english text...
> > 
> > I don't understand the problem. It's opaque from the point of view of 
> > the Web Socket protocol. It's intentionally HTTP-compatible so that it 
> > can be used with an HTTP server if that is desired.
> 
> But it's more complex than it needs to be

It's a stream of bytes. It's longer than absolutely necessary, sure, but 
how can it be more complex than necessary?


> and also contains plain english text that, as far as I can tell, doesn't 
> serve any useful purpose.

Why is using the HTTP spec's recommended text a problem?


Could you describe the actual practical problem you are concerned about?

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

Received on Sunday, 6 July 2008 10:05:46 UTC