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

I think we are in violent agreement.

Some comments inline.

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky
> Sent: Wednesday, October 16, 2002 5:49 PM
> To: w3c-dist-auth@w3.org
> Cc: Dan Brotsky
> Subject: 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.

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.

>        - 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.

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*.

>      WebDAV clients:
>
>        - SHOULD use a PROPFIND on the DAV:getetag property of a resource
>          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
>          support entity tags

Sure.

>        - MAY warn users, when authoring resources that do not support
>          entity tags, that they cannot be protected from lost updates.

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

> 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.

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 :-).

> 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.

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).

> ...
> 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...)

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

Received on Monday, 21 October 2002 15:25:05 UTC