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

[Willy Tarreau <[e-mail]>]

Hi Patrick,

On Tue, Oct 12, 2010 at 02:55:30PM -0400, Patrick McManus wrote:
> On Sat, 2010-10-09 at 22:40 +0200, Willy Tarreau wrote:
> 
> > > As I understand this suggestion, for it to provide security it relies on
> > > servers always
> > > treating any message with Connection: close as the final message. I don't
> > > know if
> > > servers always do this correctly, but since it's not really required for
> > > interoperability,
> > > I suspect that some do not.
> > 
> > I really don't buy that.
> 
> Unfortunately, Willy, I do buy it. I think I may have even implemented
> such a server :(

Interesting. Thanks for publicly admitting it. However, I hope that
your server did not return a 200 in response to a CONNECT request ?

> As you know the side that issues the active TCP close goes into
> TIME-WAIT.. My server was actually a very busy intermediary and I was
> trying to avoid building up a gigantic pile of close-waits on it...

time-waits and close-waits are very different. Time-waits are harmless
and expected. Close-waits denote a lack of close from the application
in response to a received close, on the side where they're observed.
This happens close to the end of some transfers during a short time.
Generally if they last long, it indicates an application bug, unless
the protocol supports that state (eg: a unidirectionnal FTP data
connection, or even a file transfer over HTTP when the client has
shut the send side down). Hmmm we're getting out of topic, if you're
interested, we can discuss that off-list.

> so
> the server side would not close the connection immediately after
> completing the response unless it needed to do so to delimit the
> response. instead it would presume that if the client didn't want a
> persistent connection it would close the socket pretty soon itself so I
> tossed it in the persistent reuse pool with a very short timeout -
> anticipating that the active FIN would arrive from the client before the
> timeout expired -  Which turned out to be true - I never saw a case of a
> client depending on the server closing the connection other than in
> cases without (at least) a Content-Length in the response.

In practice, connections from browsers are always HTTP/1.1 and generally
result in the servers returning a valid content-length, which the browser
always correctly interpretes. Amusingly I've seen some WAP gateways send
1.0 requests, which on some servers don't result in a content-length, thus
make the client rely on the close.

> If the client
> went ahead and sent another request I presume the code would have
> dispatched it normally even though the previous one said "close", I
> don't have access to the code to check it right now.

OK.

> > tools, otherwise you get back to the situation where both sides wait for
> > the other one to close. 
> 
> Either side is free to close at any time, right?

Yes, perfectly. Even intermediaries are free to do so. What I indicated above
was in the context of timeouts (wait for other side to close or timeout to
strike).

> > makes some sense, but saying that some won't support close clearly does
> > not.
> 
> I would agree with this regarding the "connection: close" response
> header, but not the request header. It is largely meaningless. 

Not from my observations to be honnest. It is even sometimes wrongly assumed
to be equivalent of HTTP/1.0, resulting in the server refraining from using
chunked encoding.

But thanks, at least now we have one case where Connection: close would not
have worked.

Regards,
Willy