These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with something like:
Clients requiring to verify the consistent application of a
patch document to a known entity SHOULD first acquire an ETag...
Rationale: the use of a normative keyword will draw the
attention of implementors who might otherwise not think
about this issue.
Brian
On 2009-11-18 05:03, Julian Reschke wrote:
John C Klensin wrote:
...
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.
...
It's up to the server to decide whether it provides strong or weak
etags. And it's also up to the server to decide whether you can use them
in a conditional PATCH request (RFC 2616 disallowed this, but HTTPbis is
lifting that restriction, and furthermore WebDAV never had it).
I think not stating this explicitly is the simplest approach (as this is
true for any HTTP method), but I wouldn't object to have more text
either (as long as that text wouldn't have to revised when HTTPbis is
done).
BR, Julian
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf