Re: [hybi] Web sockets and existing HTTP stacks

[Maciej Stachowiak <[e-mail]>]

On Feb 1, 2010, at 9:39 PM, Roberto Peon wrote:

> 
> 
> On Mon, Feb 1, 2010 at 7:55 PM, Greg Wilkins <[e-mail]> wrote:
> Ian Hickson wrote:
> 
> > Similarly, the server, when parsing
> > the headers in "HTTP" mode, is unaffected by the order -- and indeed, the
> > Web Socket spec doesn't require _anything_ from the server in terms of
> > parsing the client request. You can completely ignore it for all the spec
> > cares. All that matters is that you send back a specific handshake. But if
> > you're sending back the handshake, then you're a Web Socket server, so why
> > do we need to follow HTTP rules? We've already established the client is a
> > Web Socket client, so what on earth is the point of using HTTP rules?
> 
> We need to follow HTTP rules because we are in a HTTP server
> that has implemented the HTTP standard and until the CRLF
> is sent after the 101 response, HTTP rules OK!
> 
> Ian-- I know that I'd kick scream and generally raise hell about putting that in our little proxy were it not HTTP compliant until the end of the 101 response.

The current handshake response *is* HTTP compliant, it's just that the HTTP response needs to meet some additional restrictions, or it will be rejected by the client. Those restrictions include requirements to include particular response headers (apparently not controversial), to include particular text in the status line (only mildly controversial), and to require that the first two response headers headers must be two specific ones, with an exact required order and capitalization (this appears to bug people the most and perhaps creates the most headaches inside existing server code bases).

Are these restrictions a practical problem for you? If so, which are problematic, and can you describe the concrete issue? Knowing the intensity of your response is less useful than knowing the reason for it.

Regards,
Maciej