Re: websocket HTTP response parsing

On Thu, 3 Jul 2008, Julian Reschke wrote:
> > >
> > > So why then use a message format that looks like HTTP/1.1 in the 
> > > first place?
> > 
> > So that it is possible to run Web Sockets over port 80 (or 443) and 
> > have the HTTP server defer to a Web Socket server on a URL-by-URL 
> > basis. Basically the protocol is intentionally HTTP-like to make it 
> > possible to use it in environments that are currently expecting HTTP, 
> > without in fact requiring people implement HTTP if they don't actually 
> > need it.
> 
> 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.


> > > 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.

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

Received on Sunday, 6 July 2008 09:31:59 UTC