[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: Leonid Pauzner
Subject: Re: lynx-dev Why doesn't lynx cache HTML source?
Date: Mon, 16 Nov 1998 14:09:57 +0300 (MSK)

>> >Pages are becoming uncacheable either because they are dynamically
>> >generated or because uncacheability is forced in order to give the
>> Why does dynamic generation make a page uncacheable?

> This was written in the context of someone talking about following the
> formal HTTP caching rules.  Dynamic pages can be made cacheable but that
> requires a positive effort by their authors and is often contrary to the
> (often commercial) reasons why they were made uncacheable.

> For a page to be cacheable by current generation caches it needs to have
> either explicit expiry date information or a Last-Modified header.  Some

and ETag (most important).
It was a problem in HTTP/1.0 with different contents, i.e. the same document
may be available in different forms for different charset or user agant, etc,
so Last-Modified is not enought unique to be sure we right.
And every HTTP/1.1 server or proxy should (or may) send
unique ETag so the different contents cached as different documents.
Dynamically generated pages may calculate/validate ETag properly
unless a maintainer too lazy or his commercial software too stupid.

> caches may insist on it having a length as well.  Dynamically generated
> pages normally have neither although it is possible to set them.  In this
> case, the cache needs to reverify the page every time, but there is
> insufficient data to allow this to be done on a typical dynamic page,
> and it is a lot of extra work for the programmer, so most dynamic
> pages will just return a fresh copy in response to an If-Modified-Since
> request.

> Current generation GUI clients do not do what the article I was replying
> to suggested, but only reverify once per session.  The article that I was
> responding to appeared to suggest that Lynx must not use this policy, but
> must use an always revalidate policy and it was in that context that I
> pointed out the problem of dynamic pages.

Yes, history and cache are different subjects
(may have different expiration rules).

> The particular problem with AltaVista banner adverts is that the URL used
> includes the search keywords, so varies every time.  It's also in the form
> of a form reference and previous abuse of GET mode forms for really
> uncacheable material has meant that the HTTP 1.1 RFC and the default
> configuration for Squid treat a ? as indicating uncacheable material.
> Obviously Lynx doesn't have a serious problem with GIF in banner adverts!

I hope HTML form submits as POST and the responce usually have ? to indicate
info on submitting to made URL unique enough, also this is plain wasting of
cache capacity because too many different submit request may be possible...

reply via email to

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