Re: upcoming changes to TTLs.

Duane Wessels wrote:
>
>tai@nexus.hpl.hp.com writes:
>
>>> There will be a performance reduction due to the
>>> latency time on the IMS check with the source.
>>> But it ensure that there will not be a stale object.
>>
>>How about an asynchronous IMS? That is, the IMS is sent to the server
>>while returning the object from the cache (assuming it is still
>>fresh). And this can be done within, say, 20% of the object becoming
>>stale. If the object is already stale, then you have to wait for the
>>IMS. So you don't have to wait for the IMS unless the object is
>>stale.
>
>lmb@pointer.in-minden.de suggested the same thing.
>
And me thought about it for some time, too. ;) ;)

>How would you like to specify this in the config file? global option?
>stuff it in the refresh_pattern line? what are the parameters?
>
I think the sensible thing would be another pattern thingy, as some would
like 20% others 30% and with some URLs totally different tactics would
be adviseable. I'd like to be able to define a range of staleness IMS
check, like 30% before an object gets stale and 10% afterwards.

In this context I'd like to refine (more like redefine ;-) my idea about
serving stale pages (original site not reachable, etc). If this happens,
just serve it (and use HTTP 1.1 methods to signal a stale copy, if there's
such an option). But if the client does a reload (maybe limited to
pragma no_cache), generate a warning page that the original site can't
be reached for whatever reason but that stale copies can and will be served.
Sensible enuff? ^_^

Mata ne,

<CB>

-- 
  // <CB> aka Christian Balzer, Tannenstr. 23c, D-64342 Seeheim, Germany
\X/  CB@brewhq.swb.de | Voice: +49 6257 83036, Fax/Data: +49 6257 83037
SWB  - The Software Brewery - | Team H, Germany HQ | Anime no Otaku