On 21/07/2009, at 4:52 PM, Salvatore Loreto wrote:
some thoughts...a compromise could be, as I have written in a different thread, a header (or another kind of flag) that lets just the client indicate that the request is a "long-polling" one;
Yep.
and at the same time it gives the possibility to the user to set (e.g. longer or shorter it) the timeout on the server and then use different values (tune it) for different applications; it also gives the advantage to understand that the response to that request can arrive any time until the timeout expires (value indicate in the header). If the server or the proxies don't understand the header the application will just fall-back to the current situation.e.g. LongPoll-Timeout: 60
In this way you do not have a way to discover how long each hop is able to keep a connection open to the request, but we give the possibility to the client to set the time-out (e.g. an application wants just wait for 60s for a request, where the standard timeout on the server side is 300s, or the other way around).
I hadn't considered this use (at least in a hybi context).My concern is that if the client uses it to set a *lower* bound for timeouts (e.g., "I want a response in 1 second or I'm not interested"), network transit times become an issue, and there's the potential for a race condition.
The most reliable way for a client to tell the server that they're no longer interested in the outstanding response is to close the connection.
It could be also used to figure out timeouts and appropriate polling intervals: the first request is set to the largest timeout the application is willing to wait for, then if it receives an empty successful answer before the interval it has set, it can be almost sure one of the proxies or the server on the path as a lower timeout.
Sure, but the next request may go through a different path, or a different heuristic may be applied by a proxy or the server in the future.
I'm not in-principle against advertising the timeout in requests, I'm just having difficultly finding a use case where it actually adds value. In the scenario above, the client can estimate (keeping in mind the caveats) the polling interval whether or not it's told the server that it wants an interval of 60s.
Besides which, I think the common case is going to be "keep the connection open as long as you're willing to", isn't it?
Can you illustrate a scenario where the server (or an intermediary) actually uses the timeout value in the request header?
Another approach would be to run some sort of discovery protocol before polling begins, so that the client (and potentially intermediaries) can figure out timeouts and appropriate polling intervals beforehand. I'm inclined to think that this would be too complex for practical use, however; it would require significant implementation overhead (especially in intermediaries) and wouldn't be robust (e.g., in the face of more complex proxy topologies).talking about a discovery protocol, while we were writing the "draft- loreto-http-bidirectional-00", we had some ideas about the possibility to design a discovery protocol to understand which technique would be possible to use (e.g. long-polling, HTTP streaming): e.g. you are willing to use HTTP streaming as bidirectional communication technique, but you want check in advance if the proxies along the path to the server will support it. This could be useful for protocol like Bayeux that can use both the techniques.
Right, but realise that connections in HTTP aren't end-to-end. I.e., just because you connect to your proxy and make two subsequent requests on that connection, doesn't mean that the proxy uses the same connection to forward them -- or even the same path.
Cheers, -- Mark Nottingham http://www.mnot.net/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.