Re: [hybi] Web sockets and existing HTTP stacks

[Maciej Stachowiak <[e-mail]>]

On Feb 3, 2010, at 12:07 AM, Julian Reschke wrote:

> Roberto Peon wrote:
>> On Tue, Feb 2, 2010 at 5:25 PM, Maciej Stachowiak <[e-mail] <mailto:[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.
>> ...
> 
> I don't think HTTP specifies this. As Status-Phrase is just informational, I wouldn't surprised when it happened, or when it was rewritten. I'm pretty sure that there are server frameworks where it can't easily be set.

I am pretty sure a lot of popular servers do let modules/extensions/scripts running inside them set it, so I don't think this is a huge practical problem.

> 
> Anyway: if another line of defense is added (and that's how I understand Maciej's proposal), is there still a point to insist on the exact Status-Phrase?

According to a security expert I asked, the strongest defense against cross-protocol attacks is in the first few bytes. So I think removing all requirements on the status-phrase would make the protocol less robust against cross-protocol attacks.

Regards,
Maciej