Re: Retry safety of HTTP requests

On 23 March 2016 at 11:33, Mark Nottingham <mnot@mnot.net> wrote:
> Another possibility would be a pattern of use that assured that non-idempotent requests weren't able to be retried; e.g., <https://github.com/mnot/I-D/blob/gh-pages/Abandoned/http-poe/draft-nottingham-http-poe-00.txt> (I abandoned this draft because it's not really a new protocol element, it's just a pattern of use.).

That's one approach to the problem.  It's also possible to only use
POST for actions that don't have any real consequences.  For instance,
creation of a resource can be absurdly cheap.  If costly actions are
bound to idempotent methods, then you have a far more robust
application.

TLS 1.3 with 0-RTT is making some people nervous.  One of the things
that we're going to have to grapple with is how much of the
responsibility for replay we (in this working group) are able to take
on.

Now, as Amos outlined, there are many ways in which we can determine
that a retry is acceptable *according to the protocol as specified*.
The question of what is acceptable *according to the protocol as it is
used*.  There will be a subset of the first set that we want to
identify as applicable to 0-RTT [45], and maybe we need to pay a
little attention to the gap between theory and practice.  I suspect
that is where Subodh is coming from here.

[45] Obviously, anything that relies on a response from a server, like
421 or GOAWAY, isn't going to be a useful way to identify something as
being OK for use with 0-RTT.  For me, the big question is between safe
and idempotent (PUT especially).

Received on Wednesday, 23 March 2016 01:00:30 UTC