- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 08 Jul 2008 09:32:17 +0200
- 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