RE: Retry safety of HTTP requests

Another point that my colleague Daniel Sommermann brought up is that the agent that retires the application request might not be colocated on the same machine. As in the original email thread, considering the example of a load balancer that wants to retry a request to a backend service if one of the backend HTTP service goes down. Here it makes sense to have an HTTP layer flag for retries, and a browser layer flag might not work. 

>This is handled by a browser message to the effect that retrying a request
> may be risky and expecting the user to decide whether it is safe.
I agree, it's really hard for users to decide. For example if my payment for $X fails, will the browser refuse to make the request ever again or blame the user for having warned it that retrying was potentially dangerous. 

@Mark I think SEARCH might help this problem in quite a few cases, where applications could convert several of their POST queries into SEARCHes however it probably does not solve this particular user issue. I'm still checking out the Fetch spec, thanks for the pointer.

Subodh
________________________________________
From: David Morris [dwm@xpasc.com]
Sent: Wednesday, March 23, 2016 10:10 AM
To: ietf-http-wg@w3.org
Subject: Re: Retry safety of HTTP requests

As the protocol architects, we've basically punted this concern to the end
user w/o providing anything in the protocol(s) to support the end user.

It is probably impossible to avoid the possiblity that today's generation
of complex http based applications will sometimes hang at some point in
the processing of a user initiated 'transaction'.

This is handled by a browser message to the effect that retrying a request
may be risky and expecting the user to decide whether it is safe. With
applications that initiate field level data store updates w/o an explicit
user 'command', there is no way for a user to judge the safety of a
repeated request, in particular when they often don't even understand the
boundary between 'requests'.

I see (and frequently experience) the problem at the user level and sort
of understand the underlying technical problems but I don't have a
solution.

I suspect that the solution will require some change to HTTP and perhaps a
layer above HTTP. Perhaps an option for something like 3 phase DB commits
but between the useragent and application. Essentially UX tranactions to
allow roll-back/retry w/o pestering the end user to make impossible
decisions. While a very careful well done application can make it work,
protocol support could make a big difference to the vast majority of
smaller applications.

Dave Morris

Received on Wednesday, 23 March 2016 18:18:08 UTC