Re: Questions and comments about draft-ietf-httpbis-replay-00

> On 28 Sep 2017, at 10:46 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On Thu, Sep 28, 2017 at 10:35 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>> On 28 Sep 2017, at 8:47 am, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> 
>>>> Section 3, same paragraph: This is a minor nit about the use of the
>>>> phrase "side effects": I think of a GET that modifies state as having
>>>> a state-changing side effect, whereas PUT, DELETE, and POST have
>>>> state-changing *primary* effects.
>>> 
>>> I want to get the sense of the group here, I think that changing
>>> server state is what we want.  Can I reword this to:  ?
>>> 
>>> "In general, if processing a request does not alter server state, the
>>> consequences of replay are not significant."
>> 
>> We agonised over this in httpbis, and came up with <http://httpwg.org/specs/rfc7231.html#rfc.section.4.2.1>. Saying "alter server state" is too broad, since it can include things like logs, TCP state, etc. etc. What's important is 1) resource (not server) state, and 2) whether the effects are significant -- which is necessarily a judgement call. The important thing is that the party making that judgement do so with an appropriate amount of information -- which this draft is helping enable.
> 
> So maybe...
> 
> "In general, if processing a request does not alter resource state in
> a way that would affect subsequent requests, the consequences of
> replay are not significant."
> 
> ?

No - sometimes the changes might not affect subsequent requests (e.g., a drop box where the outcome isn't user-visible).

I prefer the current text in the draft; it's aligned with and refers to 7231.


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 28 September 2017 00:50:32 UTC