Re: Retry safety of HTTP requests

I think it's a bad idea to try to solve this in HTTP. It was originally
designed to be stateless, and extending it towards transactional messaging
is a road fraught with peril.

I consider it highly unlikely that enough websites will implement this
consistently for there to be a realistic hope of a consistent user
experience - and if that is eventually achieved, the transition will leave
users frustrated.

I think if a solution is worked on, it should be on a separate WG focused
on recommended application architecture  for software using HTTP as a
transport.

Phil Lello

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