W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: PATCH draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 04 Feb 2009 13:30:31 +0100
Message-ID: <49898A67.3030801@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT