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

From: Dan Brotsky <[email-masked]>
Date: Wed, 16 Oct 2002 08:48:56 -0700

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 21 Oct 2002 21:24:32 +0200

I think we are in violent agreement.

Some comments inline.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dan Brotsky
> Sent: Wednesday, October 16, 2002 5:49 PM
> To: [email-masked]
> Cc: Dan Brotsky
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>

I'm not sure about what this means. A variant may or may not have an entity
tag. If it does, it MUST be reported.

>          strong or weak entity tags.

Clarification. The DAV:getetag property MUST be *present* on a resource (for
a particular PROPFIND request), if a HEAD or GET request with the same
request headers would return an etag header. Otherwise, it MUST not be
present. We may have to discuss whether it may be reported in
DAV:supported-live-property-set, though.

Generally, all DAV:get* properties MUST be present if they would be returned
in a HEAD/GET with the same request headers, and MUST NOT be returned
otherwise. In particular, DAV:getcontentlength MUST NOT be returned as empty
if the content length is unknown (instead, it should not be present at all).
Similarily, properties such as DAV:getcontentlanguage must only be present
if the content language actually is *known*.

>          in order to determine whether that resource supports entity tags.

ETag is an entity header, so it doesn't apply to an abstract resource -- it
applies to a specific variant. We must be careful here -- there may be cases
where some of the variants of a resource have entity tags while others
don't.

>        - MAY choose not to support authoring of a resource that does not

Sure.

>          entity tags, that they cannot be protected from lost updates.

Sure. Although RFC2518-compliant locks should work as well :-)

> clients can be assured from the results of just one call what the

See above. I think we need to be careful to distinguish between the resource
and its representations (the latter have entity tags, the former don't).
Note that Roy F. says that authorable (PUTtable) resources always have
exactly one variant (but this is just one opinion :-).

> nervous about using it are closed.

I think these are caused by

- fuzzy wording in RFC2518 and
- particulary broken clients that *require* the presence of all DAV:get*
properties (even when they do not exist).

> ...

That sure is a valid workaround, but it may not be always practical:

- performance for frequent updates will be bad and
- you may use a filesystem that also has alternate access paths (for
instance as a network mount) -- in this case, you can't guarantee that
nobody *else* is modifiying the content more than once per second

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760