Re: [hybi] Web sockets and existing HTTP stacks

[Roberto Peon <[e-mail]>]

On Tue, Feb 2, 2010 at 5:25 PM, Maciej Stachowiak <[e-mail]> wrote:

>
> On Feb 1, 2010, at 11:43 PM, Roberto Peon wrote:
>
> 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.
>
>
> OK, just to clarify, are you saying that it's specifically the constraint
> on header ordering that is a problem? I'm trying to figure out which
> specific requirements are problematic and why. For example, is the
> requirement to have some special text in the status line acceptable?
>

Having some required header ordering is a problem.
As for special text in the status line, I'd have to examine the spec again
to be sure-- if proxies have the ability to drop the status text (the third
part of the first line of the HTTP response, which I'm assuming we're
talking about here), then it shouldn't be relied upon.

-=R


>
> Regards,
> Maciej
>
>
> 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
>>
>>
>
>