Re: lynx-dev '\' reloading documents

[Henry Nelson]

Maybe Lynx should do what MSIE does: feed the source (temp file Lynx
has written to disk) into DEFAULT_EDITOR rather than refetch the file
or "source cache."  That way there is no way to accidentally or otherwise
use data which is possibly no longer appropriate for hypertext operations.
(In fact, that is what I do now manually.  Go to another "screen" window
and view the file with a viewer or editor.  Perhaps '\' could optionally
offer a menu, not unlike 'p', to chose how to view the file.  This method
would have the added benefit of making pretty source obsolete -- just use
a tool designed to pull html tags, do line wrapping, hyphenation, whatever.
Good way to lose 10 kgs overnight. :)

> is there a reason why the source cache isn't used for https://?

For a long, long time source cacheing was not allowed into the code
base.  It might be worthwhile to review some of the discussion that
went on prior to and at the time source cache was finally implemented.

Some, admittedly unknowledgeable, concerns I have are:

Seems like a large proportion of documents are created dynamically
on the web these days.  In many cases it means that each page from
the server is unique, i.e., each time you access the URL, the page
that the server returns is different from any page you may have
received on previous accesses to the same URL.  A cached document in
that situation perhaps needs to have it's base URL time stamped so
that its content is not confused with the constantly changing content
of the original URL.

Does Lynx follow the server directives to not cache when source cache
is turned on in Lynx, i.e., not cache the document?  (If so, that would
explain why sometimes cacheing _appears_ to not be working.  OTOH, if
Lynx ignores those directives, that seems broken to me.)

I don't have any idea how cacheing of https would work.  Does the cache
somehow keep state on the handshake between the server and client?  Along
lines that Doug mentioned, I'd be rather concerned about any confidential
information that the server may have put into the cached source, and about
any information I may have entered into a form.

While most of you probably look upon me as reactionary, I still think that
the client should not be doing cacheing at all.  Lynx has so many ways to
easily plug into a proxy.  In addition, unlike the past, it is pretty easy
for anyone to install a fully compliant and configurable cacheing proxy.
It's very much like the recent questions about Lynx's news capabilities.
Lynx's news support is totally out-of-date and non-compliant.  Look back
in the archives to see the status on that.  Like news, is it worth
implementing cacheing if it's not going to be at least as good as what's
already available, e.g., squid?

__Henry

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden