[Top][All Lists]

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

Re: lynx-dev Why doesn't lynx cache HTML source?

From: David Woolley
Subject: Re: lynx-dev Why doesn't lynx cache HTML source?
Date: Fri, 13 Nov 1998 08:19:38 +0000 (GMT)

> Use cache - always validate cached data (see Note3):

A large proportion of web pages these days are uncacheable, often for
misguided commercial reasons.  I strongly suspect that a disproportionate
number of the ones that people will need to view source on or parse in
different ways will fall in this category.

Pages are becoming uncacheable either because they are dynamically
generated or because uncacheability is forced in order to give the
page owner, or the web hosting service, better statistics on accesses
and accessors.  Even the banner adverts on AltaVista are now dynamically
generated GIFs as far as any cache is concerned.

> use Last-Modified and ETag value from the previous request -
> add If-Modified-Since: and If-None-Match: to GET request,
> send protocol version as "HTTP/1.1"

I think this is a rather strong statement by Lynx; I believe that you 
must not send this unless you can handle anything permitted by HTTP/1.1
in reply.

> If we got 304 (not Modified) status - use cached data,
> but update header fields from this new responce.
> If we got 200 (OK) status - do as usual but do not forget to pick it up
> to the cache, with the flag for user interruption if any happen.
> If we got other status - do as usual and NOTHING for cache in any case.

RFC 2068 makes user agent caching policies more or less a local issue.
Does this new draft spec require user agents to be much more strict?  I
can think of cases where that would cause a lot of unnecessary refetches of
dynamically created pages.  Certainly current generation GUI browsers have
a strong element of local policy control and are typically set to revalidate
only once per session.

reply via email to

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