p1 7.2.4: retrying requests

<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-7.2.4>

   If an HTTP/1.1 client sends a request which includes a request body,
   but which does not include an Expect header field with the "100-
   continue" expectation, and if the client is not directly connected to
   an HTTP/1.1 origin server, and if the client sees the connection
   close before receiving a status line from the server, the client
   SHOULD retry the request. 

So, this basically requires retrying POSTs and other unsafe request methods, under certain conditions (using a proxy OR connected to a 1.0 origin server, AND conn closed before response status).

However, 7.1.4 <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-7.1.4> says:

   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 sequence of requests
   without user interaction so long as the request sequence is
   idempotent (see Section 7.1.2 of [Part2]).  Non-idempotent request
   methods or sequences MUST NOT be automatically retried, although user
   agents MAY offer a human operator the choice of retrying the
   request(s).  Confirmation by user-agent software with semantic
   understanding of the application MAY substitute for user
   confirmation.  The automatic retry SHOULD NOT be repeated if the
   second sequence of requests fails.

where non-idempotent request methods MUST NOT be automatically retried.

These seem to conflict.  A generous reading would be that 7.2 is a special case of 7.1.4, but if that's the case, it should be explicit (e.g., by placing them in the same section, or explicitly referring to each other in context).

Personally -- I'm uncomfortable with 7.2, because a) it's pretty complex with all of those conditions, and b) POST is non-idempotent, and the request may have already been processed on the server. 

I.e., AFAIK we don't have a requirement that the server MUST send a status code at the moment that the resource's state is affected, and the connection may have been closed by an intermediary.

In my experience, implementations do retry GETs, but not POSTs, and they often use a fresh connection for POSTs (et al) to avoid just this situation. 

So, I'm inclined to just drop 7.2.4, but maybe I don't know the whole story. Thoughts?

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

Received on Friday, 3 June 2011 23:06:33 UTC