ietf
[Top] [All Lists]

Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

2009-11-17 10:51:08


--On Tuesday, November 17, 2009 15:27 +0100 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)de> wrote:

John C Klensin wrote:
...
Standard etag conflict resolution is not required because
it is not desirable for many applications of PATCH.  For
other applications of PATCH, it is already defined by HTTP
and does not need to be reiterated here.

We disagree.  I believe it does "need to be reiterated here",
either in-line or by an explicit, normative, pointer to the
relevant portion of the HTTP spec.
...

<http://tools.ietf.org/html/draft-dusseault-http-patch-15#sect
ion-2> already says:

    Collisions from multiple PATCH requests are more dangerous
than PUT
    collisions, because a patch document that is not operating
from a
    known base point may corrupt the resource.  Clients
wishing to apply
    a patch document to a known entity can first acquire the
strong ETag
    [RFC2616] of the resource to be modified, and use that
Etag in the
    If-Match header on the PATCH request to verify that the
resource is
    still unchanged.  If a strong ETag is not available for a
given
    resource, the client can use If-Unmodified-Since as a
less-reliable
    safeguard.

So would replacing the 2nd part by:

    Clients wishing to apply a patch to a known entity can
first
    acquire an ETag ([RFC2616], Section 3.11) of the entity to
be
    modified, and use that ETag to make the PATCH request
conditional,
    such as by including the "If-Match" request header field
([RFC2616],
    Section 14.24).

address this concern?

Largely, yes, as long as the other changes you list below are
addressed (comments below).

Note that this makes some more changes:

1) the client can't control whether the etag will be strong,
and weak etags may work just fine in certain instances, so
just be silent about the type

Silent, no.  But saying "can't control... certain instances"
explicitly would be fine.  I'd be even happier with an
explanation of what such an instance might look like, but don't
see that as a requirement.

2) speak of "conditional requests" in general, and just
mention "If-Match" as one way to get there; there may be other
ways such as using the WebDAV "If" header

yes

3) Get rid of the text that suggests that a last modified date
somehow is better than a weak etag.

Probably a good idea.

     john


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>