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 17:11:18 UTC