Re: Retry safety of HTTP requests

On Wed, Mar 23, 2016 at 10:10 AM, David Morris <dwm@xpasc.com> wrote:

>
> 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.
>
Exactly-once delivery (RPC) over unreliable network is unsolvable ... so I
wouldn't bet on anything from HTTP to support safe-retry of POSTs.

>
> Dave Morris
>
>