Re: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1),

What I  recall from the discussions is that we do not want the ETag or
getlastmodified to change when the content of the resource stays
as it is.

Some people had the notion that ETag/lasmodified needed to change
on PROPPATCH and that is definitely not desired. However iff upon
PROPPATCH the content of a resource also changes, the ETag MUST
change.

So, saying that PROPPATCH MUST not change the ETag is not what
we want.

What the intention of our consensus-reaching discussion was is:

PROPPATCH on a resource SHOULD NOT modifiy the ETag/getlastmodified
live properties unless the content/representation of the resource
changes as well. On content changes ETag/getlastmodified MUST
change as already required by HTTP/1.1 (RFC2616).

This issue is not heavy enough to render existing implementations
non-compliant. One can look at it as a word of advise to server
implementors in order to improve HTTP caching performance.

//Stefan

Am Mittwoch, 30.07.03, um 23:58 Uhr (Europe/Berlin) schrieb Jason 
Crawford:

>
> > > I vote for the wording that is in there.  I think we've already 
> reached
> > > consensus that changing property values should not be changing 
> etags.
> >
> > Where and when?
>
> Sorry.  I don't have a particular posting that declares consensus.  It 
> was
> just what I heard over and over again in postings.  People seemed
> comfortable declaring that changing properties should not change 
> ETags.  
> There was no significant opposition to it that I recall.
>
> The issues list lists...
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html
>
> But I seem to recall that it was discussed more often than this.
>
> As you (and Geoff in the referenced page) point out, some products will
> become incompatible with 2518bis.   I believe people were aware of 
> this,
> but if they were not, you've just pointed it out.  They should speak 
> up...
>
> J.

Received on Thursday, 31 July 2003 03:31:01 UTC