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

Reply via email to