Re: HTTP If-* headers

Am Freitag den, 26. April 2002, um 18:41, schrieb Clemm, Geoff:

> Whenever the topic has come up in the past, it has always
> become clear that there will always be some live properties
> that will change without updating the DAV:getlastmodified
> or DAV:getetag values, that some implementations will update
> these values when dead properties (and certain live properties)
> change, and that other implementations will never update these
> values for any property change.

That is the current state of affairs, yes.

> So there is little useful we can say about the relationship
> between property values and the If-* headers.

Hmm. I think it would be useful to say that ETags should only
change on content modifications. In my understanding HTTP
caches are encouraged by HTTP/1.1 to validate on ETags.
WebDAV enabled servers could improve caching if PROPPATCH
and friends would not change ETags.

So, a recommendation in a future version of 2518 makes sense,
don't you think?

//Stefan

> Cheers,
> Geoff
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Friday, April 26, 2002 12:19 PM
> To: w3c-dist-auth@w3c.org
> Subject: HTTP If-* headers
>
>
> You saw this coming, didn't you? ;)
>
> The HTTP If-* header family, namely
>
> If-Match, If-None-Match, If-Modified-Since,
> If-Unmodified-Since and If-Range
>
> are described in rfc2616 as they apply to
> GET, HEAD and PUT.
>
> But what about the WebDAV methods? I think we need
> to clarify and put an advisory in an updated rfc2518.
>
> Easy things first: If-Range seems only to make sense
> with GET. So we could exclude it from discussions of
> other methods.
>
> The other four, IMO, should be honoured on DELETE,
> COPY, MOVE, LOCK and UNLOCK.
>
> But what about PROPFIND? For the If-* headers to make
> sense with PROPFIND, a client would rely on the
> assumption that DAV:getlastmodified and DAV:getetag
> change when properties are changed (either by PROPPATCH
> or as a side-effect on live properties from other
> methods.)
>
> Would the burden on the server (to update etag/lastmodified)
> justify the benefit? I rather doubt that, but would like
> to hear the opinion of the excellent audience on this list.
>
> //Stefan
>

Received on Friday, 26 April 2002 13:06:52 UTC