Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:

>> But for starters... let's make the upgrade request not just look like a HTTP request, let's make it a real HTTP request.  Then intermediaries and servers would be free to add
>> new headers and do funky HTTP stuff without needing to involve the browsers.
> 
> I don't have anything against this suggestion per se, but it doesn't seem to solve either of the problems raised above:

It doesn't solve the problems, but it enables more standard solutions to them.
It also does not break intermediaries and servers just for giggles.

>> Then for the timeout problem, we actually need the same solution for long polling as for websockets.   We need a standard header that expresses the idle timeouts, which can be
>> checked by all intermediaries and either respected or adjusted by them.
> 
> It seems like we need a mechanism for that which is robust in the face of unaware intermediaries. One way I can think of to do that is to encode the information in a hop-by-hop
> header. Unaware intermediaries would (I hope) just drop it, while aware intermediaries could read it and update the information. Thus, you only get a header indicating WebSocket
> awareness if both the origin server (or client) and all intermediaries are aware, and your idle timeout lower bound would be based on the minimum of all participating endpoints
> and intermediaries.
> 
> Some set of headers is defined to be hop-by-hop: <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.1>. The Connection header can also be used to cause additional
> headers to be treated as hop-by-hop headers: <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10>. One thing I don't know is whether deployed intermediaries respect
> this. Do they respect the fixed list of hop-by-hop headers? Do they treat headers listed in the Connection header field as hop-by-hop?

I think a hop-by-hop header is exactly what is needed, so that any non transparent
proxy would have to explicitly copy the timeout value from input to output.

This would still be an issue for transparent proxies that try to not look like
a hope, but at least the argument could be made that the timeout value is there
in the header so they should at least respect it.

So this header will not initially solve the problem, because of non compliant
intermediaries.   However, together with orderly close, it would allow non compliant
intermediaries to be detected (and new connections with shorter idle timeout
re-established).


>> Ideally there could be some non 101 return codes that could be sent so that a websocket client and a websocket server could have several rounds of negotiation for things like
>> credentials, timeouts and maybe even redirections!
> 
> That might help with the origin server, but does it help with intermediaries? If intermediaries would normally just pass through a 101, then you cannot tell if an intermediary
> would time you out faster than your origin server.

Intermediaries often respond to a request on a servers behalf.  They may need
their own authentication or they may do a redirect themselves.

So in a chain A-B-C,  perhaps A-B will first negotiate in a few exchanges
and then A-C will negotiate before the connection is established.

So websocket needs to define what happens when a upgrade request is
responded to with a 401, 302 etc.

regards