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

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Jun 2010 12:12:22 +1000

FYI. 

Begin forwarded message:

> From: [email-masked]
> Date: 9 June 2010 12:00:01 PM AEST
> To: [email-masked]
> Subject: I-D Action:draft-loreto-http-timeout-00.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Hypertext Transfer Protocol (HTTP) Timeouts
> 	Author(s)       : S. Loreto, et al.
> 	Filename        : draft-loreto-http-timeout-00.txt
> 	Pages           : 12
> 	Date            : 2010-06-08
> 
> A Timeout header is defined for Hypertext Transfer Protocol (HTTP).
> This end-to-end header informs an origin server and any
> intermediaries of the maximum time that a client will await a
> response to its request.  A server can use this header to ensure that
> a timely response is generated.  This also identifies requests as
> being potentially long-lived, and allows for better resource
> allocation for these requests.
> 
> A Connection-Timeout header is defined for HTTP.  This hop-by-hop
> header informs the entity at the other end of a connection of the
> maximum time that an idle connection is kept open.  This header
> improves reliability by providing better information about the idle
> connection management policy of HTTP hosts.
> 
> Comments and feedback for this draft should be directed to the
> authors and the Apps Discuss list ([email-masked]).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-loreto-http-timeout-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham     http://www.mnot.net/

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 09 Jun 2010 14:31:03 +1200

My initial comments...

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.

That raises a couple of questions for me.

1. Why not use a 1xx response to keep the connection alive?

This will keep intermediaries (including NATs) alive.  HTTP already 
mandates that HTTP/1.1 agents support this, empirical evidence has not 
been gathered about whether proxies typically block these or pass them 
through.

This would avoid the need to send a "NULL" response, close and re-open.

This also solves the issue where the server may not be in a position to 
ensure that a response is given within any timeframe communicated by the 
client, since the server can in any case send back a 1xx response.

2. Is this a use case for allowing entities on a 1xx response?

I'm sure this would break a heap of things, but perhaps the actual 
communication of the change in state could also be communicated in the 
1xx response, if not in an entity, then perhaps in a carefully formatted 
(experimental?) header.  Then multiple events could be signalled over 
the same connection.

Regards
Adrien

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Jun 2010 12:01:32 +0800

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

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 09 Jun 2010 18:06:03 +1200

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 10 Jun 2010 07:18:09 +0800

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

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

--Martin

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 10 Jun 2010 11:34:23 +1200

> 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 automatica…

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?

> 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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 10 Jun 2010 07:42:39 +0800

> could send the request to the server.

That's not the scenario that this mechanism seeks to avoid.  The idea is that a new connection is less likely to time out during the (non-idempotent) request than one that has been sitting idle for a while.  This is a hop-by-hop thing.  

Obviously, if the request was going to fail anyway (at any hop), there's no gain.
 
> > To the extent that it ensures that the connection remains open, sure.
> You still need to know when the 1xx is required.
> >
> 

We seek to do away with such heuristics.  They are brittle and inefficient.

 --Martin

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jun 2010 09:46:41 -0700

My .02 -

First of all, the Timeout HTTP header field is already defined and registered:
  http://www.iana.org/assignments/message-headers/perm-headers.html
  http://www.rfc-editor.org/rfc/rfc4918.txt
... so you'll need to choose a different name.

I'm inclined to think that passing specific timeout values from the client to the server isn't useful, and sometimes dangerous (because it will encourage creation of race conditions). The vast majority of intermediaries (whether HTTP, NAT, etc.) will NOT change this value according to their configuration, and so its value can't be trusted. For that matter, when set from some client tools (e.g., XHR), there won't even be any visibility into the local implementation's various timeouts; the value set will therefore be a shot in the dark.

Furthermore, most client applications will want to set it for "a lot," without having any more specific guidance.

All of this leads me to believe that there's little value in setting a timeout; what we really need is just a flag that says "I'm long-polling here." It's a lot easier to implement support for this (e.g., in Squid, Apache Traffic Server, elsewhere), and more difficult for it to cause problems.

Regarding Connection-Timeout, why not just codify the Keep-Alive timeout parameter? It's already implemented in Apache (and others, IIRC).

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 1 Jul 2010 07:02:27 +1000

On 30 June 2010 02:46, Mark Nottingham <[email-masked]> wrote:

> I'm inclined to think that passing specific timeout values from the client to the server isn't useful, and sometimes dangerous (because it will encourage creation of race conditions). The vast majority of intermediaries (whether HTTP, NAT, etc.) will NOT change this value according to their configuration, and so its value can't be trusted.

Part of the idea of this mechanism is to give the intermediaries a
mechanism where they can actively signal their intent. I'm guessing
that current intermediaries do not signal their intent mostly because
there is no mechanism fo r them to do so, not because of any
unwillingness to do so.

regards

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Jun 2010 18:30:44 -0700

Yes, but see my other points -- I don't think the information is particularly useful. AFAICT there's only one really significant bit of information here -- "I intend to long-poll."