NEW ISSUE(S): Retrying Requests

> 14.37 Retry-After
> The Retry-After response-header field can be used with a 503  
> (Service Unavailable) response to indicate how long the service is  
> expected to be unavailable to the requesting client. This field MAY  
> also be used with any 3xx (Redirection) response to indicate the  
> minimum time the user-agent is asked wait before issuing the  
> redirected request. The value of this field can be either an HTTP- 
> date or an integer number of seconds (in decimal) after the time of  
> the response.
>    Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
> Two examples of its use are
>    Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
>    Retry-After: 120
> In the latter example, the delay is 2 minutes.

Issues;

1) 14.37 mentions 3xx methods and 503 as valid placements; in addition  
the definition of 413 refers to Retry-After. The text of 14.37 should  
be updated to include 413.
2) 10.3 (3xx codes) doesn't mention Retry-After; it should be added  
there, or 3xx should be removed from 14.37 (I suspect the latter,  
since AFAIK this isn't implemented).
3) What is the relationship between retry-after and the Cache-Control:  
max-age on those responses? (for the 503 case, I wonder if CC: max-age  
is a better practice than Retry-After)


> 8.1.4 Practical Considerations [of persistent connections]
>
> Non-idempotent 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.


Issues;

4) This is defined in the context of persistent connections that have  
closed, which is fine, except that retry behaviour for idempotent  
requests isn't defined anywhere else; the reader has to deduct that  
it's possible by reading between the lines here. Since automatic  
retries are implemented in a number of places (client and  
intermediary), I think it should be at least mentioned in a way that  
isn't just specific to connections closing, and as a MAY, not just a  
MUST NOT on non-idempotent requests. I.e., I think request retries (as  
opposed to connection retries) deserves its own section.
5) The text in 8.2.4 (below) needs to be taken into account in this  
section (e.g., by qualifying the MUST NOT and SHOULD NOT with a  
reference to it).

> 8.2.4 Client Behavior if Server Prematurely Closes Connection
> If an HTTP/1.1 client sends a request which includes a request body,  
> but which does not include an Expect request-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 any status from the server, the  
> client SHOULD retry the request. If the client does retry this  
> request, it MAY use the following "binary exponential backoff"  
> algorithm to be assured of obtaining a reliable response:
>
> 1. Initiate a new connection to the server
> 2. Transmit the request-headers
> 3. Initialize a variable R to the estimated round-trip time to the  
> server (e.g., based on the time it took to establish the  
> connection), or to a constant value of 5 seconds if the round- trip  
> time is not available.
> 4. Compute T = R * (2**N), where N is the number of previous retries  
> of this request.
> 5. Wait either for an error response from the server, or for T  
> seconds (whichever comes first)
> 6. If no error response is received, after T seconds transmit the  
> body of the request.
> 7. If client sees that the connection is closed prematurely, repeat  
> from step 1 until the request is accepted, an error response is  
> received, or the user becomes impatient and terminates the retry  
> process.

Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com

Received on Wednesday, 5 March 2008 04:28:28 UTC