On Monday 05 September 2005 09:27 am, Geoff Davis wrote:
> On Mon, 05 Sep 2005 18:15:41 +0200, Florent Guillaume wrote:
> >>> If an FSPageTemplate is associated with a Caching Policy and that
> >>> Caching Policy has 304s explicitly enabled, a series of checks take
> >>> place. If there is an If-Modified-Since header, the server checks the
> >>> modification time associated with the template via the Caching Policy.
> >>> If there is an If-None-Match header and the Caching Policy defines an
> >>> ETag function, the ETag is checked. If all the checks pass, the server
> >>> returns a 304 status and stops without rendering the page. The server
> >>> does less computation, and less data goes over the wire, so it's a
> >>> double win.
> >> If I'm not mistaken, this will only be useful for ZPTs that provide
> >> unchanged content over time ? Like css or scripts or invariant
> >> resources, i.e. not useful for the usual case of views ?
> If you write your ETags in an appropriate way, this works beautifully for
> views. Consider an ETag that consists of a string containing (1) the
> content object's modification date, (2) the user name for the currently
> authenticated user, and (3) the current time rounded to the nearest
> hour. If a user gets this content while logged in, the ETag will match
> (1) when s/he is logged in, (2) if the content has not changed, and (3) if
> the cached copy is less than an hour old. You get cached, personalized
> content that is guaranteed not to be stale and has an expiration time
> that you control. Very good stuff.
Except for any dynamic portlets on the page, but that's what ESI is for I
guess. AJAX loaded content areas (which themselves could be cached with an
ETag) would help here as well.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests