- From: Dan Brotsky <dbrotsky@adobe.com>
- Date: Wed, 16 Oct 2002 08:48:56 -0700
- To: w3c-dist-auth@w3.org
- Cc: Dan Brotsky <dbrotsky@adobe.com>
Once again, sorry for being so long about joining this thread. I'll try to phrase this proposal in a way that I think addresses all the issues that have been raised. I excerpt arguments from various pieces of mail in what follows, and I apologize in advance if you feel I do not do your point justice. Proposal: Add the following language (adapted from 2616 and 2518) to 2518-bis: WebDAV origin servers: - MUST send an entity tag validator unless it is not feasible to generate one. - MAY send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entity tags, or if it is unfeasible to send a strong entity tag. - MUST NOT send either a strong or weak entity tag in response to any request on a resource unless it ALWAYS sends such a tag in response to every such request. - MUST define the DAV:getetag property for any DAV-compliant resource if and only if it responds to GET requests with strong or weak entity tags. WebDAV clients: - SHOULD use a PROPFIND on the DAV:getetag property of a resource in order to determine whether that resource supports entity tags. - MAY choose not to support authoring of a resource that does not support entity tags - MAY warn users, when authoring resources that do not support entity tags, that they cannot be protected from lost updates. I think this addresses the following issues which came up in the discussion: 1. Servers are not required to support etags for resources for which it is infeasible to do so. However, they are required to be completely consistent about whether they do or not for a given resource, so that clients can be assured from the results of just one call what the situation is. 2. Julian's excellent suggestion for how clients should figure this out is made a SHOULD, and the loopholes that might have made clients nervous about using it are closed. 3. In moving from DRAFT to PROPOSED standard, we are simply strengthening a SHOULD clause to a MUST. (The SHOULD clause, by the way, was in 2616, not 2518, but since every 2518 server MUST also be a 2616 server this still counts.) 4. Geoff eloquently raised the issue that we should not suddenly make compliant servers into non-compliant servers unless we have compelling reason to do so. I believe that what we are doing here is to force consistent support for etags (as opposed to last mod dates, or some other mechanism) by those servers WHICH ARE CAPABLE OF IT. I believe there are servers out there which could support etags (because, for example, they support last-mod dates) but which do not support them simply because the spec does not require them to. I believe we have a very compelling reason to require those server implementations to meet the higher standard of compliance: it allows clients to know, in a consistent manner, whether they can support the avoidance of lost updates when authoring against that server, and exactly how they can do it. This is a primary goal of the protocol. 5. Geoff also pointed out: > On a related topic, working to marshall new functionality through > existing machinery rewards an implementor for going to the effort of > being > fully compliant, and increases the likelihood that implementors will > bother > to do so. I believe that this is exactly an effort to marshall new functionality (allowing clients to avoid lost updates) through existing machinery (etags, which were already in 1.1) and that we will, in fact, be rewarding those implementors who went to the effort of being fully compliant with 1.1. 6. Jason was concerned that we not require something which may be infeasible, but was in favor of making it "very clear that [etags] do provide value and should be implemented if possible." I hope he can support this proposal as meeting both those goals. 7. Julian was concerned that servers which, for example, simply serve simple filesystems (using no additinal machinery) might not be able to meet this requirement, and that in their desire to meet it they would accidentally produce buggy implementations. I think his more general point (that people sometimes produce buggy implementations when specs get more stringent or require new features) is unassailable, but in this particular case: - if they don't see how they can't support etags then they're OK, cause they don't have to. They just have to NOT support etags consistently :^). - I believe that, in such a case, the filesystem's internal timestamp is arguably a fine thing to use as an etag. If the DAV server in question doesn't allow changes except to content (which presumably it doesn't because it has no other machinery to store properties with, and the filesystem properties are not generally mutable), then using the timestamp as an etag is quite reliable, the server simply has to ensure that no two PUT requests are processed within the resolution of a single filesystem timestamp value. And, as Geoff would say :^), how hard could this be? (Sorry, couldn't resist...) dan
Received on Wednesday, 16 October 2002 11:49:28 UTC