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

I just read through a couple more times.

I can understand the value in a host advertising how long it is willing 
to hold a connection open if no data is received / sent on it.

Basically it's an advertisement that the peer shouldn't expect the 
connection to still be usable if it doesn't send something in that 
amount of time.

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.

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.
In the case where there is a proxy and  the server fails during 
processing and no response is sent to the proxy, an error can be 
reported to the client also.
In the case where the client is talking directly to a server, the server 
could still fail and give not response. This could happen whether or not 
a fresh connection was made.
So why can't we rely on the response to determine the action?

My comments on using an interim response only really make sense to 
address issues relating to long polling, since you can't send a 1xx 
without there having been a request already made.

What are you referring to when you mention a "null response"?   Is this 
like a 204 response?  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.

Regards

Adrien


On 9/06/2010 4:01 p.m., Thomson, Martin wrote:
> Hi Adrien,
>
>    
>> There's quite a bit of overlap between the purpose of this I-D and the one I've been working on recently discussed on this list relating to progress notifications.
>>      
> While I can see how the two proposals might interact (constructively), and the use cases might be similar, there is little actual overlap in mechanism.
>
> The only potential for overlap would be if you were to make Connection-Timeout less than Timeout, which we specifically exclude.  Then, you would need a way to keep the connection alive and progress notifications could fill that role.
>
>    
>> 1. Why not use a 1xx response to keep the connection alive?
>>      
> To which mechanism do you refer to?
>
> For a Timeout, the intent is not to use this as a connection keep-alive or anything of that nature.  A 1xx response could be used if the request is _really_ long-lived (see above), but we're not there just yet: first we need to know how long this request might take.  Thus, the header.
>
> For Connection-Timeout, the main use case is the idle connection where there is no outstanding request.  So you have no vehicle for the 1xx.
>
>    
>> 2. Is this a use case for allowing entities on a 1xx response?
>>      
> I don't think so.  It probably would not play well with existing implementations [1], which is a bit of a deal breaker.
>
>
> --Martin
>
>
> [1] http://tools.ietf.org/html/rfc2616#section-10.1
>
>

Received on Wednesday, 9 June 2010 06:06:44 UTC