- From: Lisa Dusseault <lisa@xythos.com>
- Date: Wed, 26 Feb 2003 11:36:27 -0800
- To: "'Jason Crawford'" <nn683849@smallcue.com>, "'Clemm, Geoff'" <gclemm@Rational.Com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
> Just so that you know you're not alone... what Julian suggests sounds > reasonable. OK, this is really starting to sound like consensus, but I want to make sure we explore the options. I don't want to accept a consensus based on arguments that I don't think are valid, even if the consensus might be right I'd like to know why by seeing valid arguments. I've attempted to rebut the two arguments I believe to be invalid. Please explain why I'm wrong if you think the arguments are in fact valid (perhaps I haven't understood the arguments). Or, please explain what other arguments remain for making Etags optional. 1. The argument that "Etags are too difficult to support". Is the problem with strong etags that they're hard to implement for all resources? Or only for PUTtable resources? The requirement could be that servers supporting "bis" MUST support strong Etags in response to successful PUT requests. Given this, I think it's easy. RFC2616 only says: A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality... An entity tag MUST be unique across all versions of all entities associated with a particular resource. A given entity tag value MAY be used for entities obtained by requests on different URIs. The use of the same entity tag value in conjunction with entities obtained by requests on different URIs does not imply the equivalence of those entities. That means that Etags could be almost as simple as a sequence number plus possibly some file/url string. A digest of the contents would also work. Supporting strong etags is actually easier than supporting weak etags. It may be slightly time-consuming to generate etags depending on what algorithm you choose, but the time is insignificant compared to the time it takes to receive a PUT request, check access controls and store the body. Next, no WebDAV server should have any problem storing the ETag. Any server capable of storing dead properties is capable of storing an etag generated on PUT. A server that cannot store ETags is already likely to be massively non-compliant. I might consider a cost-benefit argument to be a valid argument -- although I believe the benefits are high and thus the cost would have to be even higher to outweight. However, I don't consider "too difficult to support regardless of the benefits" to be a valid argument. 2. If 2518bis requires support for Etags, this doesn't retroactively make servers like IIS5.0 non-compliant with 2518. That's a historical standard and we can't change that even if we wanted to. On the other hand, there will be several requirements 2518bis which will make servers compliant with 2518 have to do some work to be compliant with 2518bis: - Making LOCK on an unmapped resource create a regular empty locked resource (not a lock-null resource) - Supporting commas in if header syntax - Evaluating all clauses in an if header even if they are tagged with a URL to which the request does not "apply" - etc... Given that we are already making more requirements on servers in 2518bis than we did in 2518, I do not see the "making servers non-compliant" argument as a valid argument. Lisa
Received on Wednesday, 26 February 2003 14:36:30 UTC