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

Re: PATCH draft

From: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>
Date: Wed, 04 Feb 2009 18:04:47 +0000
Cc: Lisa Dusseault <lisad@messagingarchitects.com>, ietf-http-wg@w3.org
Message-Id: <8FA44B8E-8748-4582-911F-3CEC1147C717@messagingarchitects.com>
To: Julian Reschke <julian.reschke@gmx.de>




Sure.  But the client code I sent would break that server's model.   
There's nowhere in the spec that says that you can compare a weak ETag  
to a strong ETag by stripping the "W/".

Lisa

On Feb 4, 2009, at 4:30 AM, Julian Reschke wrote:

> 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
>


--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.
Received on Wednesday, 4 February 2009 18:16:01 GMT

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