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