On Thu, May 29, 2003 at 10:50:46AM +0900, Henry Nelson wrote: > 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."
I am confused. What temp file? If there were one then surely we wouldn't have this problem. > That way there is no way to accidentally or otherwise > use data which is possibly no longer appropriate for hypertext operations. I thought we were talking about "view source" - in which case it's plain text, not hypertext. I'm obviously completely missing the point of what you are saying... > > 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. Yes, and irritating it is too. I wish I could get more browsers to ignore the gratuitous no-cache pragmas that some sites send. > 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. If I view the source then I generally want to see the source of the page I'm looking at right now, not the source of the page that would have been generated if I'd asked for it right now (and without the Referer header, which makes a big difference on certain kinds of site). > 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? It keeps the source of the document which you are viewing - I don't see what handshaking has to do with it. > 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. But I've already got the document - if anything was confidential then it's too late! No one else is going to see it if it's only cached in memory. > 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? That's ridiculous... most Linux installations don't come with squid unless you ask for a full or server install, and I'm not about to bloat my system with that just so I can use Lynx properly. imc ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
