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

[Maciej Stachowiak <[e-mail]>]

On Jan 29, 2010, at 11:19 PM, Greg Wilkins wrote:

>> That is a valid concern. I think it would be a problem to design a
>> protocol where buy-in from intermediaries is required to deploy at all,
>> because that would greatly delay the deployment timeline. However, you
>> have pointed out a real problem with not knowing how intermediaries will
>> react, namely that you don't know if you need to take special measures
>> to hold the connection open.
>> 
>> I think the right way to approach this, and issues of intermediary
>> participation, is to have optional opt-in from intermediaries. I would
>> like to see a design where at least the SSL version of the WebSocket
>> protocol can operate with no need to change proxies or other
>> intermediaries, but where if proxies or other intermediaries are updated
>> to opt in, there's a way for both the client and server to know that,
>> and to be able to make certain default assumptions, for instance how
>> long the connection is held open even if completely idle. Do you have a
>> concrete proposal?
> 
> I've made many many concrete proposals.... so many that I've lost
> track as they've all been rebuffed.   I don't really care how the
> issue is solved... it just needs to be solved.
> 
> 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:

- Letting intermediaries indicate that they are aware of WebSocket (perhaps allowing you to assume a default minimum timeout, and maybe with other benefits.)
- Knowing a lower bound on your idle timeout so you can avoid sending excessive messages just to keep the connection alive.

It might help provide a mechanism for this, but it's not even totally clear to me how it would.

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


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

Regards,
Maciej