RE: NEW ISSUE: Methods and Caching

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 UTC