Re: [hybi] Web sockets and existing HTTP stacks

[Roberto Peon <[e-mail]>]

Simple-- the proxy won't know that the response from the server is websocket
specific, and may reorder things.
You should not assume that the termination point (the "host") is a server.
It could be a reverse proxy. In such cases, the proxy needs to treat the
response as HTTP until it has been fully read and interpreted.

This response IS HTTP, so HTTP rules apply. It isn't a some random
more-restrictive subset of the response rules. It is still HTTP at that
point. That means that you don't get to add additional restrictions on that
request. If you do, then you're creating headaches for everyone.

Now, I may kick and scream, etc. but I certainly can be convinced that the
effort to change is worthwhile if the reasons are not arbitrary.
What advantage do we get from requiring special behaviors from the
servers/proxies in this case? I can't think of any benefits, thus my
response!

-=R

On Mon, Feb 1, 2010 at 10:11 PM, Maciej Stachowiak <[e-mail]> wrote:

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