Persistent connections and POST

Quotes from RFC 2068

8.1.4 Practical Considerations
....
   This means that clients, servers, and proxies MUST be able to recover
   from asynchronous close events. Client software SHOULD reopen the
   transport connection and retransmit the aborted request without user
   interaction so long as the request method is idempotent (see section
   9.1.2); other methods MUST NOT be automatically retried, although
   user agents MAY offer a human operator the choice of retrying the
   request.
   
   However, this automatic retry SHOULD NOT be repeated if the second
   request fails.

9.1.2 Idempotent Methods

   Methods may also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

My interpretations and what I deduce of this:

1. Non-idempotent methods can't be sent on a persistent connection since
the client/proxy has no means of knowing if the origin server is closing
down the connection and it is not allowed to retry the request if it
fails (which it may on a persistent connection). Examples of known
non-idempotent requests are POST and cgi-bin requests. It is however
allowable to reuse the connection used for a idempotent request after
the non-idempotent request has finished.

2. When retrying a request this has to be done on a new connection. It
is not allowable to retry failed requests on other persistent
connections. Why: Only one retry is allowed, and if a persistent
connection was used then more retries may be needed..

3. We are not allowed to retry a request if the connection succeeds but
the origin server or proxy fails to process the request (zero size
reply). In other words: If the request was the first request on this
opened connection, then is it not allowed to retry the request.

It is however allowable to retry the connect operation as many times as
you like, since a connect alone is idempotent in that it does not cause
any side effects (or should not cause any..).

Currently Squid retries the connection a bit to much, even on some POST
requests (small body immediately avaialable). This may get very
unpleasant effects if Squid is used in an environment where such retries
is fatal. A good example I know of is where a GET/POST request reboots a
device without sending a reply.. Imagine Squid retrying this request 10
times (which by the way is a lot more than the allowed 2 times)..

/Henrik
Received on Tue Jul 29 2003 - 13:15:55 MDT