Re: [hybi] Handshake was: The WebSocket protocol issues.

[Willy Tarreau <[e-mail]>]

On Sun, Oct 10, 2010 at 09:17:21PM -0700, Eric Rescorla wrote:
(...)
> Thus, it's quite possible to implement an HTTP server which does not
> deadlock
> without looking at the Connection header at all, simply by having a short
> timeout.

That's what I meant with the "deadlock", we can only end the transfer on
a timeout if the client expects a close and the server does not close.
Even if the timeout is short, it makes the situation very uncomfortable
for the user.

> Moreover, even treating the *presence* of a Connection: close as an
> indication
> of there being no more requests is merely a SHOULD level requirement
> (S 14.10):
> 
>   HTTP/1.1 defines the "close" connection option for the sender to
>    signal that the connection will be closed after completion of the
>    response. For example,
> 
>        Connection: close
> 
>    in either the request or the response header fields indicates that
>    the connection SHOULD NOT be considered `persistent' (section 8.1)
>    after the current request/response is complete.

Indeed, however two lines below the requirement is a MUST for the client :

   An HTTP/1.1 client that does not support persistent connections MUST
   include the "close" connection option in every request message.

> Accordingly, it's not at all clear to me that it's safe to rely on
> Connection: close

Well, the best way to wipe any doubt would be to test it on a variety of
servers.

BTW, I believe that Adam's example was that he could write a program on
a shared server that could return a valid handshake to the CONNECT request.
But since the valid response is a 200, by definition it's an establishment
of a tunnel between both sides, which ends only by the close. So once again
there is no other request on the wire after the handshake (rfc2817, #5.3).

(...)
> I'm not convinced that that's true: Adam has already explained how to make
> a
> content aware load balancer that speaks Websockets, simply by having the
> Host header appear in the encrypted portion.

I don't agree with that point at all. We're doing the same mistake again
that we did with -76 handshake : the intermediaries should not wait for
the connection to be completely established to take a routing decision.
Look at this very common example :

                       <--- hosting provider's infrastructure --->

                                   /---- server farm A
  client --- internet --- content <----- server farm B
                          switch   \---- server farm C

Some server farms are shared and other ones are dedicated to some
customers, which is the typical scenario we find at almost every
hosting provider's, because some customers with very poor code,
high traffic or nasty reputations can cause negative side effects
on other sites if shared on the same farms. Here, an HTTP content
switch (reverse proxy and/or load balancer) will simply look at
the host header and forward the request accordingly to the proper
server.

With Adam's proposed handshake, this is not possible anymore with
currently deployed components. We would have to implement WebSocket in
all front components just so that they can decrypt the host header and
see what farm is supposed to process it, if any at all. Not only this
is not compatible with existing HTTP infrastructure, but doing so makes
the frontend component sensible to new DoS attacks because it has to
maintain a context before even knowing if it has to handle the request.

Regards,
Willy