- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 04 Feb 2009 13:30:31 +0100
- To: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>
- CC: Lisa Dusseault <lisad@messagingarchitects.com>, ietf-http-wg@w3.org
Julian Reschke wrote:
> ...
>> This spec text doesn't require strong ETags to be used by the server.
>> It sidesteps the issue that we have no clue what a weak ETag would
>> mean and how a client could reasonably use it -- it just says what the
>> client can do if it gets a strong one. Your proposed text could lead
>> clients very astray if a weak ETag was used as defined in RFC2616, and
>> a PATCH was applied to a document that has slight changes from what
>> the client thought it would be.
>
> But it's the server that mints the etags (decided on strong vs weak),
> and also which implements a specific PATCH format. Thus, it seems, it's
> best to let the server decide whether it can execute a given conditional
> request.
> ...
...adding an example:
Consider a server that uses an XML database as backing store, which thus
uses weak etags because it can't guarantee to preserve the ordering of
attribute values. That server wouldn't be able to support a binary patch
format (as in "set octet x to y"), but it could support a patch format
that is based on the XML Infoset ("insert element <foo> after the node
selected by XPath..."), even for weak etags.
That's why I think the server should have the last word on this.
BR, Julian
Received on Wednesday, 4 February 2009 12:31:13 UTC