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: Adrien de Croy <adrien@qbik.com>
Date: Thu, 10 Jun 2010 11:34:23 +1200
Message-ID: <4C1024FF.5050801@qbik.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.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>


On 10/06/2010 11:18 a.m., Thomson, Martin wrote:
> 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.
>    

I don't see what the difference is between a new proxy connection 
returning a 504 (e.g. the proxy can't connect to the server) vs proxy 
reporting 504 connection aborted on an old connection before the proxy 
could send the request to the server.

So relying on that seems misguided to me.

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

OK, I understand they may do that (albeit deludedly).  Should we solve 
it by adding more headers which we may not be able to believe anyway, or 
fix the clients / proxies so that errors of that nature can be reported 
reliably and non-idempotent requests safely retried?

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

Sure, that could use the same heuristics at the server that a client 
would use.

Cheers

Adrien

> --Martin
>
>    
Received on Wednesday, 9 June 2010 23:35:04 GMT

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