Re: Idempotent partial updates

tis 2012-02-28 klockan 10:23 -0800 skrev Martin Thomson:

> Is it always true that a PATCH request with an If-Match header
> containing a strong ETag is idempotent?

Per the definition of strong etag and If-Match it's safe but not really
idempotent in the view of the client (response differs), but server
state is idempotent. Except that it's not spelled out anywhere that I
know of.

This under the condition that the server do implement If-Match. But
given that it's an MUST condition it's quite reasonable to expect
If-Match to be implemented in the cases of partial updates and similar
if ETag is.

> I don't think that any of the other conditional headers can be used to
> make a statement of the same certitude.

If-Unmodified-Since can also be considered a strong enough condition
under certain conditions, but it's hard for an intermediary or server to
verify that these conditions are fulfilled as it's dependent on the Date
of the earlier response in relation to it's Last-Modified. But it's
accepted as a safe tradeoff to simply trust that the client only uses
If-Unmodified-Since in situations requiring a strong validator under
such conditions that the carried Last-Modified value is considered
strong.

>  Of course, there are plenty
> of requests that could be non-idempotent, but - if you understand the
> context - are actually idempotent.  That's the point of contention: is
> it desirable that this property be observable (thanks Carsten)?

It's very desirable that it's well known when idempotence can be
unconditionally assumed based on the request alone, as it relates to
when requests can safely be retried at the transport layer in response
to transport failures/events, and also have direct impact on safe use of
transport features such as connection keep-alive and pipelining.

>From this follows that it's important that requests defined as
idempotent is not implemented in an non-idempotent manner as it could
easily result in hard to diagnose timing dependent breakage and
corrupted data.

It also desirable that idempotent methods are used for idempotent
actions, but using requests defined as non-idempotent for idempotent
actions do not cause any breakage, only slight loss of efficiency.

Regards
Henrik

Received on Wednesday, 29 February 2012 22:19:10 UTC