W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

RE: Fwd: I-D Action:draft-loreto-http-timeout-00.txt

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Thu, 10 Jun 2010 07:18:09 +0800
To: Adrien de Croy <adrien@qbik.com>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Greg Wilkins <gregw@webtide.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F1F9EC@SISPE7MB1.commscope.com>
Adrien writes:
> I can understand the issue between negotiating this on a hop-by-hop
> basis so a client can know how long an idle connection (no request sent
> yet) may be usable.  However the discussion of long-polling confuses
> this, since long-polling is different, it's not later use of an idle
> connection for a request, it's a delayed response.

That's right.  The discussion of long-polling relates to a request (Timeout) rather than a connection (Connection-Timeout).
> However I don't understand the issue where you discuss non-idempotent
> requests, and using a new connection.  I don't know what this actually
> gives you.
> In the case where there is a proxy, and say the proxy starts sending
> the
> request on an idle connection to a server at the same time as the
> server
> closes the connection, then the proxy will report an error to the
> client, and the server never got the request, and the client can retry.

That's precisely the problem - they can't.  If you send a non-idempotent request, it's not safe to retry the request.  Without a response you have no idea what happened.  You can't retry automatically.

Many HTTP implementations create a new connection for non-idempotent requests, which reduces the chances of losing the connection.  That's inefficient.  Hence: Connection-Timeout.
> What are you referring to when you mention a "null response"?   Is this
> like a 204 response?  

I've seen 200, 204, 304 - it matters little, though we should probably clarify that point :)

> I guess if intermediaries are between the client
> and server, the next request could come in on another connection.
> However if you used a 1xx response, the same connection could be used
> to
> send the final response when an event actually occurs.  So I believe
> 1xx
> response has benefits for long polling.

To the extent that it ensures that the connection remains open, sure.  You still need to know when the 1xx is required.


Received on Wednesday, 9 June 2010 23:16:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:39 UTC