[Top][All Lists]

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

Re: lynx-dev '\' reloading documents

From: Ian Collier
Subject: Re: lynx-dev '\' reloading documents
Date: Thu, 29 May 2003 11:12:31 +0100

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

> 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.


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

reply via email to

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