Henrik Nordstrom wrote:
>
> Dancer wrote:
> > I already have code for 1.1.(20-ish) that prevents implicit or
> > explicit refreshing of objects that match certain refresh_pattern
> > rules (magic 'max' age of 1).
>
> Sounds like a handy feature if implemented in a nicer manner (i.e. use a
> explicit option keyword instead of magic values).
What I might do is exactly that. The underlying mechanics rely on the
same mechanics as refresh_pattern in any case, but a different keyword
(immortal/never_stale/whatever) would probably make things a lot
clearer.
> > 2) I subscribe to unofficial RFC -1: "Know when to break the rules. Do
> > it carefully. Do it cleanly. Do it knowing what you are letting
> > yourself in for."
>
> I agree with this, and this is why I don't like the current (1.1.22,
> 1.2b22) refresh_pattern behaviour. It was to easy to override Expires:
> without being aware that this is a protocol violation (or even that it
> is overridden)
Agreed. If we override it, we should do it because it's what we intend.
> ---
> Henrik Nordström
> Sparetime Squid Hacker
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E- W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ ------END GEEK CODE BLOCK------Received on Sun Jul 12 1998 - 07:22:12 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:05 MST