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.

--Martin

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:20 GMT