W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

RE: NEW ISSUE: Methods and Caching

From: Brian Smith <brian@briansmith.org>
Date: Tue, 18 Nov 2008 06:55:15 -0600
To: <werner.baumann@onlinehome.de>, <ietf-http-wg@w3.org>
Cc: <ietf-http-wg@w3.org>
Message-ID: <013c01c9497c$e81fa490$b85eedb0$@org>

Werner Baumann wrote:
> RFC 4918 says:
> "Some PROPFIND results MAY be cached, with care, as there is no cache
> validation mechanism for most properties."
> 
> Additionally the response to a PROPFIND request is highly client
> defined. With three levels of DEPTH and about 10 properties defined in
> RFC 4918, there are about 3000 different possible responses for the
> same state of the same resource. And clients are free to create any
> number of custom properties. Nothing an intermediary cache would like
> to cache.
> 
> Apart from the method the intermediary cache would have to include the
> DEPTH header and a list of requested properties into the key. And what
> would be the cache hit rate?

For other depths, a cacheable propfind should include a "Vary: *" and
validators (ETag and/or Last-Modified). "Vary: *" is needed since the
response depends on the request body. Then the cache can cache the response
just as it would for any other use of "Vary: *", by passing through the
PROPFIND as a conditional request.

Additionally, if a WebDAV server doesn't support infinite-depth request,
then it can return a 403 with a long expiration time and "Vary: Depth". The
cache can cache all of these very effectively.

For any given WebDAV client, there are not many different types of PROPFIND
queries done on a resource. And, often there are repeated PROPFIND queries
done on the same resource, so it makes sense to support caching with
revalidation.

- Brian
Received on Tuesday, 18 November 2008 12:55:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:57 GMT