On Thu, 2 Mar 2000, Ivan Zakharyaschev wrote:
> On Tue, 29 Feb 2000, Klaus Weide wrote:
> > be in the cache of rendered documents, and lynx will not automatically
> > reload it when you follow the link again. But it should be rendered
> > correctly after you do a ^R)eload (or any of the other commands that
> > imply reloading, like <*>, <'>, <`>, <]>). Or, alternatively, if you
> > use 'x' instead of Enter to follow the link.
>
> OK, some of this work, some don't. ^R)eloading does work (and <`>, <'>,
> <*> - which reload the document), but retrieving the head by pressing <]>
> doesn't help.
Sorry, my mistake: i meant <[> (INLINE_TOGGLE), not <]> (HEAD).
> Of course, that's not so important. Using 'x' instead of
> Enter to follow a link doesn't make the browser render the document
> correctly.
>
> > If this was not the case, please give example URLs. (Something in
> > those pages might cause unusual behavior, for example HTTP headers
> > or META tags.)
> >
> > Also, if caching soesn't explain what you see, try the alternative
>
> Generally, caching explains all this but there are two points that run
> across my ideas about caching: first, the browser retrieves the document
> for quite a long time (I mean, it isn't done just at one moment, not as if
> the document would have been stored on the local filesystem), and
> secondly, the cache isn't updated (so when I load the document assuming
> the right charset, it isn't stored another time in the cache). Maybe I'm
> just a lamer and I don't know how it works.
It's not really obvious, and maybe it isn't explained well enough
how these interact:
(1) There is a "cache of rendered documents". This has been in all lynx
versions (or, at least, all versions I have seen). Controlled by
-cache=NUMBER and DEFAULT_CACHE_SIZE. If a document is taken from this
cache, it should appear immediately (except perhaps if the computer is
low on memory or extremely slow).
(2) There is a "source cache", in the latest versions; it only applies
to HTML and the http: (and https:, if using lynx with SSL) protocols.
(But if you compile with DEBUG_SOURCE_CACHE defined, it applies to all
protocols - but still only to HTML documents.) It needs to be enabled
with SOURCE_CACHE in lynx.cfg.
(3) If you have set up lynx to go through a proxy, there may be another
level of caching (or even more than one) at the proxy(/proxies).
^R and 'x' should always be "hard" reloads: the content is re-fetched from
the origin server (we even tell the proxy - if one is used - with appropriate
HTTP to get a new copy). THe document should be completely re-rendered
under the current settings.
<*>, <'>, <`>, <[>, <@> etc. cause a "soft" reload; differences are:
(a) if SOURCE_CACHE is on and lynx has cached the source, the cached copy
will be used (and re-rendered according to current settings); and (b)
if a proxy is used, it is allowed to give us a cached copy.
Just following a link again that you had followed before will, in general,
just re-display the document from the "cache of rendered documents" if it
is still there. (Exceptions: you use 'x' - see above; or Lynx has marked
the document as "no-cache", maybe because of HTTP headers or because it
is a POST form submission or because it is a page generated by Lynx for
some special purpose.) Just returning to an already loaded document with
the Left Arrow key also re-displays the document from the "cache of
rendered documents" if it is still there (there should be no exceptions,
unless you use -resubmit_posts). Re-accessing a document from the History
Page should also act like this (no reloading, unless 'x' or -resubmit_posts
is used).
For the situations in the last paragraph, but if the document is *not*
in the "cache of rendered documents", it will of course be reloaded.
"Softly", except that (a) above cannot occur (if it's not in the "c.o.r.d.",
it shouldn't be in the "source cache" either), so the lynx code doesn't even
look in the "source cache".
The 'O'ptions Menu (both incarnations) is special in some respects:
when returning from it after changing some options, lynx may reload the
previous page rather than showing the version from the "c.o.r.d." again.
Whether that happens, and whether that's a soft or hard reload, depends on
which options were changed, and may also depend on the URL (protocol) of
that previous page.
(Question esp. to Leonid: is all this still valid?)
Now, the above was mostly talking about the *contents* of documents, in
either source or rendered form. But there is also meta-information about
documents, kept separately by lynx (in HTParentAnchor structures, for the
most part). This includes charset information. It is possible that lynx
handles the document contents itself correctly, but sometimes improperly
remembers some meta-information for too long when it should have been
discarded. Lynx could then re-render a document under some assumption
(like assumed charset) that shouldn't be used any more, rather than the
current global setting. And due to differences from other key commands
in how LYK_NOCACHE ('x') is implemented - there is no call of
HTuncache_current_document() from mainloop() - this would more easily
happen for 'x' than for other keys.
So I ask again for a URL where you observed this; also please let us
know the sequence of page visits and other actions that lead to to
behavior ("Using 'x' instead of Enter to follow a link doesn't make the
browser render the document correctly"). Also whether you had
SOURCE_CACHE enabled or not (or whether the same behavior occurs in
both cases).
Also, you were using 2.8.3dev.14, and there have been significant
changes in this area since then (esp. wrt source cache). Could you
get the latest devel code from <http://lynx.isc.org/current/> and
check whether the same problem still exists.
Klaus
