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 [EMAIL PROTECTED]
