lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev cache control


From: Klaus Weide
Subject: Re: lynx-dev cache control
Date: Sun, 12 Sep 1999 13:51:09 -0500 (CDT)

On Mon, 13 Sep 1999, Vlad Harchev wrote:
>  Here are my thoughts:
> Ignoring cache-control in some incarnation can be useful not only for lynx -
> so this could be implemented at the proxy level

If everyone had a caching proxy, we wouldn't need caching in lynx at
all, or at least SOURCE_CACHE wouldn't have come into existence.
"You can use a proxy" used to be the answer to people who wanted
source caching, apparently they didn't buy it...

> (I don't know, may be squid
> already has the features for ignoring cache control, and anyway, any
> cache-control ignorance scheme Klaus described (stale time, etc) will be
> easier to implement in squid, that already has all means for supporting
> expiry date, etc, rather than hacking lynx source.) 

Lynx already has the means to parse expires etc., it already does time
comparison based upon it (although not in the best way).  Expires,
Lat-modified, Cache-control are already stored in the node_anchor for
each document (although only in string form, mostly just for display on
the '=' page.  All it would take would be to make use of that information...
(i.e. check for "freshness" in HTLoadDocument or similar.) Algorithms for 
calculating freshness can be found in later libwww versions from W3C, they
are not that difficult.  Making some parameters user-configurable would
be a natuaral part of adding these missing pieces.

> In order proxy level to
> work, it should cache everything according to it's logic, but provide data
> with 'no-cache' pragma so that all requests will pass through it. 

Is that your idea of how proxies in general work?
It's not a good idea.

Why add unnecessary traffic between the browser and the proxy?
The proxy may not be running on localhost.

Also consider that lynx would reset all changed form fields each time
you go "forward" (follow a link) to something that is already cached.

>  But temporary hack like IGNORE_CACHE_CONTROL:YES seems to be useful too
> (probably wrapped in conditionals, to be defined controlled by 'configure') if
> you don't have enough time.

And then later, if more complete controls are added, add
IGNORE_LAST_MODIFIED and IGNORE_THIS and SET_CACHE_THAT?

Another unnecessary explosion of lynx.cfg options that could be
handled as one option by designing more flexibly (thinking ahead).
(Henry, say something...)

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]