W3C home > Mailing lists > Public > public-html@w3.org > July 2008

Re: websocket HTTP response parsing

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 08 Jul 2008 09:32:17 +0200
Message-ID: <48731801.1030208@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: "public-html@w3.org" <public-html@w3.org>

Ian Hickson wrote:
> On Mon, 7 Jul 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> We can't. If the handshake occurs after the first byte sent over the 
>>> connection, it would be far too easy for someone to smuggle in a fake 
>>> handshake.
>>>
>>> Furthermore, one of our core requirements is the ability to implement 
>>> a Web Socket Protocol server without any HTTP server involvement, and 
>>> so we can't build this on HTTP.
>> I was asking to *relax* the server requirements (by allowing the server 
>> to return variants of the response that are equivalent from an HTTP 
>> point of view) -- how would that make a server implementation harder?
> 
> If you're not proposing building this on HTTP (i.e. the server is just to 
> pretend to do an HTTP response and then do the handshake instead of the 
> HTTP response being the handshake) then it's not more complicated, it's 
> just longer. I had assumed you wanted the server to properly handle HTTP.
> ...

My assumption was that this protocol uses an HTTP-like format to make it 
*possible* that the case indeed is handled by an HTTP server, passing 
then the TCP connection to a different component.

If this is the case, it should be defined in a way so it actually works. 
If this is not the case, I wonder why it uses an HTTP-like format?

BR, Julian
Received on Tuesday, 8 July 2008 07:33:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:56 UTC