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

[Maciej Stachowiak <[e-mail]>]

On Jan 30, 2010, at 2:23 PM, Greg Wilkins wrote:

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

I don't know whether the hardcoded handshake format it the right tradeoff overall. But reasons have been given for it, so I don't think its fair to call it "just for giggles". If you can explain how making the HTTP upgrade handshake more flexible would help solve specific problems, then it would be easier to do a cost-benefit analysis.

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

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

Copy or adjust, if its idle timeout is lower than the last server it talked to.

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

Sounds like the hop-by-hop header design is broken in the face of transparent proxies, if they do indeed preserve hop-by-hop headers. Is that truly the case for deployed transparent proxies? How common are they? (The reason I say it breaks the feature is because you'd have no way of detecting whether you are going through an unaware transparent proxy, so you can't tell either whether your path is really clean, or whether the idle timeout you got is accurate.)

It also seems like the hop-by-hop header technique does not work for WebSocket over SSL. That's a pretty serious problem, because I think that's the only case that is likely to work over most unmodified proxies. Any idea how to address the SSL case?

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

There's really two problems to be solved:
(a) Detect that your path to the origin server, including all intermediaries, consists solely of WebSocket-aware servers.
(b) Determine some information about the max idle timeout, which is valid if based on (a) you detected that you have a fully aware path.

I don't see how a close handshake would allow unaware intermediaries to be detected. The handshake would presumably be done by the origin server and would not even take the form of an http message. If WebSocket can go through the intermediary at all, then the handshake is likely to go through unmodified. Are you saying that if you don't see the handshake you should assume an intermediary timed you out? That seems like a poor assumption, because any number of network failures could have interrupted a connection. Also, how long do you assume that your path to the client or origin server is going through the same proxis?

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

I don't entirely understand how your proposal would work. But the issue I'm raising is that if the origin server or an intermediary responds with a 101, that doesn't tell you if there were any unaware intermediaries in the path between you and them. So it does not solve the problem of knowing you have buy-in from intermediaries, or computing your idle time-out.

Regards,
Maciej