W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Retry safety of HTTP requests

From: Wenbo Zhu <wenboz@google.com>
Date: Wed, 23 Mar 2016 11:19:43 -0700
Message-ID: <CAD3-0rOAp=h97L-jyaLJpEn5Hk9VzOgWLU-r+vpRGyshaoYkKg@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Wednesday, 23 March 2016 18:20:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 March 2016 18:20:16 UTC