Re: websocket HTTP response parsing

Ian Hickson wrote:
> On Mon, 7 Jul 2008, Julian Reschke wrote:
>>> We need a handshake that can guarantee that we've contacted a 
>>> WebSocket server and not some other server that's being tricked into 
>>> sending data that looks like the handshake. For that purpose, we use 
>>> the headers that come before the server has to echo anything, and we 
>>> make that as long as possible (and as unique as possible) by moving 
>>> both those headers there.
>> I don't understand this point. Could you (or somebody else) please 
>> elaborate?
> 
> Which part don't you understand, the need for a handshake, the requirement 
> that the handshake not be one that an existing server can be tricked into 
> sending, or the description of the currently defined handshake?

"The requirement that the handshake not be one that an existing server 
can be tricked into sending".

>>>>>> Also, did you consider the impact of intermediates in the 
>>>>>> request path?
>>>>> You mean, like proxies? Sure, the spec defines how to handle 
>>>>> those.
>>>> What if they somehow modify the reason phrase? It would be outside 
>>>> the control of the server, and communication would break.
>>> Any proxy that did that would be deeply violating HTTP rules and would 
>>> also be breaking TLS tunnels.
>> Which HTTP rule would be violated by a proxy rewriting the reason 
>> phrase?
> 
> Wouldn't it be a violation of CONNECT semantics?

I didn't talk about CONNECT.

> It seems to me that if the way of handling proxies defined in HTML5 for 
> Web Socket doesn't work, then there's no way TLS could work either. Is 
> that wrong? How would TLS work if the tunnel wasn't opaque?

The tunnel is opaque, once you get it. But the 101 status message isn't 
part of it necessarily.

>> I'd prefer though to use HTTP semantics (making the text of the reason 
>> phrase irrelevant), or to use an empty reason phrase.
> 
> Making it irrelevant would make it easier to smuggle this over another 
> protocol, which is what we're trying to avoid. It would also increase the 
> odds of bugs in clients.

I'm not sure what exactly these concerns are.

>> It's one reasonable string, but again (and again...): the HTTP spec does 
>> not give it any semantics, and servers may vary in what they send, for 
>> instance because of the locale of server, or Accept-Language.
> 
> Well, now they have a particular handshake string they have to send for 
> this case.

Well, we will see whether it works in practice.

>> In addition to the reasons I gave (and that you don't seem to care 
>> about), it's a strange way to design a protocol by making a plain 
>> english text fragment part of the exchange.
> 
> As opposed to the rest of the English stuff like "HTTP" and "Web" and 
> "Socket" and "Connection" and "Upgrade" and so on?

Those are different in that they actually have semantics.

>> - the reason phrase has no semantics in HTTP, so it's a bad idea to make 
>> something look like HTTP but then make the exact byte sequence in the 
>> reason phrase important
> 
> Why? You keep saying it's a bad idea, but it seems like a good thing to 
> me. It makes the handshake more resilient. Why does it cause a problem?

More resilient against what? What for? What is the problem you're trying 
to solve by requiring that kind of match?

Making things look like a specific protocol, and then to treat them 
differently in general is problematic. If it's HTTP, parse it as HTTP. 
If not, don't make it look as if it was.

>> - servers/libraries may not allow sending arbitrary reason phrases
> 
> Servers/libraries will have to be upgraded to handle WebSocket anyway, so 
> this isn't a big deal.

The question is how much of the existing code needs to be upgraded.

>> - servers/libraries may vary reason phrase based on locale information, 
>> so you may be testing something in the US, and it works, and later it 
>> will fail when the software is deployed somewhere else
> 
> The failure mode is fatal here, so that's fine; it would be caught early. 

It would *potentially* caught early, if tested properly.

> Indeed, now that we have a hard-coded unique string, implementors would 
> have to go out of their way to translate it, so this seems unlikely.

With the changed string, it's more likely that problems are detected 
early, and this is indeed good.

>> - intermediates could rewrite the reason phrase
> 
> Given the semantics described in the spec, I don't see how this is 
> possible.

Well, I disagree.

BR, Julian

Received on Monday, 7 July 2008 11:15:52 UTC