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

[Patrick McManus <[e-mail]>]

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 :(

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... 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. 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.

> 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?

> 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.