- From: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>
- Date: Wed, 04 Feb 2009 18:04:47 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Lisa Dusseault <lisad@messagingarchitects.com>, ietf-http-wg@w3.org
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 UTC