Re: websocket HTTP response parsing

Ian Hickson wrote:
> On Thu, 3 Jul 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> ...
>>> This isn't HTTP. It's WSP (Web Socket Protocol), which while it may vaguely
>>> look like HTTP in the handshake, really isn't HTTP and shouldn't be treated
>>> like HTTP.
>>> ...
>> 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...

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

BR, Julian

Received on Thursday, 3 July 2008 16:32:07 UTC