W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: ETags

From: Eric Sedlar <esedlar@us.oracle.com>
Date: Thu, 17 Feb 2000 16:01:11 -0800
Message-ID: <024401bf79a3$44da71a0$ab171990@us.oracle.com>
To: "Greg Stein" <gstein@lyra.org>, "WebDAV WG" <w3c-dist-auth@w3.org>
Given that most filesystems allow you to update the modification date
directly whenever you want, I think the MAY language is fine.  Using the
modification date is always based on convention, for this reason.

However, if I had to choose, I would say updating a property SHOULD change
the modification date.  The properties should be considered part of the
resource entity.  Otherwise, for example, would the ACL for a resource not
apply to the properties, if they are not part of the resource entity?  Would
you have a second ACL restricting access to the properties, separate from
the ACL for the resource data itself?  The implications of the properties
NOT being part of the resource entity gets too yucky.

Perhaps WebDAV should RECOMMEND that the modification date be updated when
properties are updated, to set the convention, but not require it.

--Eric

----- Original Message -----
From: Greg Stein <gstein@lyra.org>
To: WebDAV WG <w3c-dist-auth@w3.org>
Sent: Thursday, February 17, 2000 2:30 PM
Subject: RE: ETags


> I think that we have to say MAY. Consider the case where properties are
> stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the
> date will change when you store a property. While reasonable to state that
> the server implementation is required to restore the modification date to
> the original (before storing the property), I think that is getting into
> dangerous territory. What if your backup solution is using the
> modification time to backup that multi-stream file? Or maybe there is
> another storage mechanism where a server couldn't restore the date(!).
>
> Putting a MAY into the spec is fine. Yes, the client won't know what the
> server is going to do, but that isn't that big of a deal. For most of the
> live properties, the client won't always know what will happen when they
> touch the resource.
>
> Cheers,
> -g
>
> On Thu, 17 Feb 2000, Kevin Wiggen wrote:
> > I could probably make up just as compelling reasons why the ETag and
> > Last-Modified-Date SHOULD change during a update of a dead property etc.
> >
> > But
> >
> > I agree that it seems that no other server can (or is) supporting this.
I
> > can pull this functionality out of Xythos.
> >
> > I just read Greg's email, and I don't like putting the MAY in the spec.
A
> > client will never know what the server is doing.  I think we just need
to
> > pick a position and put it in 2518.
> >
> > I am fine with changing properties does not modify the ETag or
> > Last-Modified-Date.  But I think we should be consistent.
> >
> > Kevin
> >
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> > Sent: Thursday, February 17, 2000 12:03 PM
> > To: WebDAV WG
> > Subject: FW: [Moderator Action] RE: ETags
> >
> >
> > Accidentally caught by the spam filter.
> >
> > - Jim
> >
> > -----Original Message-----
> > From: Clemm, Geoff [mailto:gclemm@rational.com]
> > Sent: Wednesday, February 16, 2000 7:56 PM
> > To: w3c-dist-auth@w3.org
> > Subject: [Moderator Action] RE: ETags
> >
> >
> > A good reason to not change the etag or mod-date when a property changes
> > is that a property is often information about the resource, as opposed
to
> > "being" the resource.  If I mark a resource as being "tested", I don't
want
> > it to appear that the resource has changed (thus making it look like I
need
> > to test it again).
> > A less compelling reason (but still a consideration) is to achieve
> > consistency
> > between dead and live properties.  You certainly don't want a change to
the
> > "last access time" of a resource to modify the etag or "modification
time"
> > of
> > that resource.
> > Add to this the fact that current implementations appear to not modify
the
> > etag or
> > modification time when a dead property is modified, and I think we have
a
> > pretty
> > case that neither the etag value nor the modification time should
> > be changed when a dead property is updated.
> >
> > Cheers,
> > Geoff
> >
> > > -----Original Message-----
> > > From: Kevin Wiggen [mailto:wiggs@xythos.com]
> > > Sent: Wednesday, February 16, 2000 4:12 AM
> > > To: w3c-dist-auth@w3.org
> > > Subject: ETags
> > >
> > >
> > >
> > > I searched the spec and could not find any special details on handling
> > > ETags.
> > >
> > > Should an ETag value be updated when a dead property is
> > > changed?  On the
> > > same note, do most servers update the last-modified-date when a dead
> > > property is changed?  Does Webdav want to take a stand one
> > > way or another?
> > >
> > >
> > > Curious,
> > > Kevin
> > >
> >
>
> --
> Greg Stein, http://www.lyra.org/
>
>
Received on Thursday, 17 February 2000 18:59:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT