RE: FW: ETags again - basic question

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 9:29 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: FW: ETags again - basic question
>
> ...
>
> So anyway, we agree with each other again -- we can't forbid servers to
> change an Etag when the entity doesn't change. All the spec can do is
> recommend with SHOULD.

Agreed.

> > > 3.  Clients who are editing with a lock might issue a
> > PROPPATCH, then
> > > try to issue a PUT with an ETag validation. If the ETag has
> > changed due
> > > to the PROPPATCH, then the client will be very confused
> > whether or not
> > > the file can be overwritten. The lock still appears to be
> > there, yet the
> > > ETag changed -- how did that happen?
> >
> > That's indeed a problem. I think the correct way to handle
> > this would be to
> > optionally return a new entity tag after PROPPATCH (just like
> > PUT is doing
> > it).
>
> Unless this were part of the spec, I'm not sure clients would notice an
> Etag on a PROPPATCH response.  Otherwise, that's a good idea.

So we may want to add this to RFC2518bis (if a PROPPATCH modifies the etag,
it SHOULD be returned in a PROPPATCH response).

> This list has discussed in the past defining a new calculated property
> to allow the client to tell when dead or unprotected properties have
> changed -- a Property Tag or PTag, perhaps.  Has the day come for that
> idea?

I always liked that for symmetry reasons. But how does this help with the
original problem?

Julian

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

Received on Tuesday, 4 March 2003 16:25:11 UTC