cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Encoding problems
Date Wed, 12 Mar 2003 12:14:27 GMT
Carsten Ziegeler wrote:
> 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 :-(


Mime
View raw message