Santiago Gala wrote:
Re: cache comments later:
When I was discussing Cocoon (then new) cache ideas with Ricardo Rocha, (so around winter 2000/spring 2001) I sent an idea to Cocoon-dev about propagating the CacheValidity to set the Expires in the seriazed output. It looked like a clean (the only clean way I have found to date in any famework) to set the "expires:" header in a web publishing framework. AFAIK it got lost in the sea of bits. If any of you set on fight against the cache, it could be very worthwhile. And I would have contributed another bits to Cocoon ;-)
In theory it is possible to set the expires header and to propagate the cachevalidity. But (currently) the cachevalidity does not hold any expires information. In most cases it contains a last modification date of the used files (xml/xslt).
Carsten
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.
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
Also note that I always suggest this in the worst possible moment (at beta stabilization time :-(
