Santiago Gala wrote: > > > Last-Modified: could be filled with this (the aggregated semantics for > it is clear, I think: the highest modification date in the compound > validity object). For objects implementing "dynamic" retrieval, like xsp > sheets, they should set "now" and a close to zero expiration date > > This would allow for requests with If-Modified-Since: set to return a > small body (304), saving a lot for quasi-static GETable resources. > > quoting from 2fc2616 (Last-Modified): > > > The exact meaning of this header field depends on the > implementation of the origin > > server and the nature of the original resource. For files, it may be > just the file > > System last-modified time. For entities with dynamically > included parts, it may be the > > most recent of the set of last-modify times for its component > parts. For database gateways, > > it may be the last-update time stamp of the record. For > virtual objects, it may be the last > > time the internal state changed. > > Specific Cache validities could allow for extended semantics, like > expiration dates, proxy directives to avoid caching out of the container > (thus revalidating requests every time "must-revalidate") or dictating a > "max-age", etc. > Yes, ok - should be possible.
> Note: I have not seen the cache code in at least a year, I'm referring > to Ricardo's design ideas and availability just before cocoon-2.0 > Yes, I know them :) because I used them as a starting point for implementing the cache. > Also note that I always suggest this in the worst possible moment (at > beta stabilization time :-( Oh don't worry about that, we can handle this :) Carsten
