Re: ETags, was: Issues from Interop/Interim WG Meeting

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