Re: #297: p1 7.2.4: retrying requests

Hi Mark,

On Sun, Jun 26, 2011 at 04:49:06PM +1000, Mark Nottingham wrote:
> >> I think we should figure out whether we need consistent behaviour regarding retries between products, or it's just something that we allow implementations to do, based on the known semantics of some request methods.
> >> 
> >> I tend to view it in the latter way; given that you can never guarantee that clients won't see failure, retries are just an optimisation, not something we need full interop on. 
> > 
> > Retries on persistent connections should remain mandatory, as there is
> > no way to know that the connection is closing while sending a request.
> 
> They're SHOULD NOTs now, and I suspect that many implementations don't do it.

When I performed some tests, both firefox and MSIE 6 were able to retry the
second request on a persistent connection if that connection was closed
before a response would be sent. However I must admit that my tests were
only for simple GET requests, there was no body.

> >> My current thinking is to life the retry-specific text out of 7.1.4 into a new section, possibly adding advice (along the lines you mention). 
> >> 
> >> I'm inclined to propose removing section 7.2.4 altogether, because it's very specific to a certain kind of request (one with a body where the connection drops to a proxy or HTTP/1.0 server, when there isn't an Expect: 100-continue header), and doing so can result in the server seeing a non-idempotent request being repeated multiple times, which is bad.
> >> 
> >> I realise that's a fairly big change. Is anyone aware of any actual implementation of 7.2.4?
> > 
> > It is possible that some of them exist, it's been noted as 8.2.4 in RFC2616
> > for the last 12 years :-/
> 
> Yes, but if it's problematic for interop we can change it. 

True.

> What do other folks think about this? Personally, I'm concerned about clients retrying POSTs; I think this will surprise many folks server-side, and can cause some problems. Semantically, POST (for example) is very clearly non-idempotent, and retrying under these circumstances opens a race condition.

I agree that retrying a POST is *always* problematic, because the only one
who knows whether it's safe is the application. That said, it's not a problem
until all the body has been sent. But in general, the most sensible retries
will have small bodies (eg: delete first mail in a webmail, or validate a
payment).

Still we must offer provisions for UAs to guess if it's safe to emit a non
idempotent request over an existing connection. Expect is fine when the
server is 1.1. It becomes trickier if the body is empty. Maybe we could
reintroduce the Keep-Alive header with clear semantics ?

> > Also I suddenly have an idea : why shouldn't we recommend that an
> > intermediary which must retry but can't would send a 5xx status
> > explicitly asking the client to retry ? It could be a lot cleaner
> > than closing and expecting the client to retry on a failed first
> > request, and even if the client does not handle this specific 5xx
> > status, at least it would get an indication about what went wrong.
> > Maybe it could be a 503 + Retry-After.
> 
> 
> I think 504 is more appropriate for a proxy, and the ability to retry is
> implicit in its semantics

504 is commonly encountered when the server fails to process the request
in time because of external dependency (webservice, database, etc...).
In my experience, it's very common to encounter 504 in complex
infrastructures, but the request are fully received and eventually
processed. It's just that a gateway between the client and the server has
enforced a timeout which is shorter than what it took the server to process
the request.

502 would be cleaner since it corresponds to a failure to send the whole
request to the next step. I proposed 503 because I saw that it supports
the Retry-After header, but as you pointed, it does not seem that UAs are
implementing it anyway.

> (I don't know of any software that automatically retries based upon a Retry-After header). 

My quick tests seem to agree with you :-/

> Effectively, this is what happens already (after all, you have to give up retrying *sometime*), but I don't see any harm in spelling that out.
> 
> I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/297> to track this.

Thanks. I'll keep trying to figure out solutions which require minimal effort
for each participant in a communication.

Cheers,
Willy

Received on Sunday, 26 June 2011 15:53:30 UTC