RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Thursday, November 28, 2002 3:55 AM
> To: Webdav WG
> Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>
> The issue of requiring ETags was brought up at the WG mtg, as one of the
> remaining 2518 bis issues.  The discussion covered dynamic resources,
> and a couple possible methods to generate ETags without too much pain
> (using combinations of sequence numbers, timestamps, hashes of resource
> names or content.).  Most interestingly, there was also a suggestion
> that ETags could be required only for resources that can be PUT to.

This makes sort of sense. However, I still don't see why this should be a
requirement. A client that requires entity tags can trivially find out
whether a resource supports them. If the resource doesn't support entity
tags, but the client needs them, don't attempt the operation.

I do agree with the earlier consensus that servers must be consistent in
what they say about etag support (per ressource), notably that DAV:getetag
must be present as property if and only iff HEAD/GET return the etag as well
(but this is just a clarification, not a new requirement).

> I think I'm satisfied with this compromise, because it's precisely in
> the situation when a client is trying to PUT a resource body, that ETag
> support is needed.  We've already discovered since 2518 was published

Actually, that requires *strong* entitity tags as opposed to weak entitity
tags, right? If you make strong etags a requirement, Apache moddav (when
talking to a fs backend) becomes non-compliant. Have you considered that?

> ...

Julian

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

Received on Thursday, 28 November 2002 03:59:19 UTC