Received: by taz.hyperreal.com (8.6.12/8.6.5) id CAA21368; Mon, 11 Mar 1996 02:32:12 -0800 Received: from mauve.csi.cam.ac.uk by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id CAA21354; Mon, 11 Mar 1996 02:31:58 -0800 Received: from cass41.ast.cam.ac.uk by mauve.csi.cam.ac.uk with SMTP-CAM (XTPP8.1) as ppsw.cam.ac.uk; Mon, 11 Mar 1996 10:29:37 +0000 Received: from mamba.ast.cam.ac.uk by cass41.ast.cam.ac.uk (SMI-8.6/SMI-SVR4) id KAA27035; Mon, 11 Mar 1996 10:31:18 GMT Received: by mamba.ast.cam.ac.uk (Smail3.1.29.1 #9) id m0tw4sk-0000kiC; Mon, 11 Mar 96 10:31 GMT Message-Id: Date: Mon, 11 Mar 96 10:31 GMT From: drtr@ast.cam.ac.uk (David Robinson) To: new-httpd@hyperreal.com Subject: Re: cache verification Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Status: O X-Status: > On Sun, 10 Mar 1996, David Robinson wrote: > > > 1: I stole the Last-modified factor from the CERN server, so your last > > statement is false. > > No, it's not. As I understand it, CERN uses that directive to determine > when to get rid of the cached file. i.e. it caches the file until the > time figured out from the Last-modified header times the factor runs out, > but it still does a conditional GET each time. Hmm, you may be rght. > > 2: You can achieve the behaviour you want by setting the last-modified > > factor to zero; then all documents without an Expiry header will 'expire' > > immediately. > > But this is not very desirable, as it then entails retrieving the whole > document each time. No it doesn't. It still caches the document. > > 3: The behaviour of not checking the remote server is very useful; > > for a lot of people a cache that always checks the origin server can > > be worse than useless for small documents. (small = few hundred bytes). > > > Average size of a web document is about 5k. Average size of a 304 > response sent to a conditional GET: 90 bytes. I said small documents! For these, the limiting factor is the RTT; the saving of one network packet for a conditional GET compared to a document fetch is often not significant. > > There is no overriding reason to treat a missing Expire as 'expire now'. > > In a lot of cases that is the wrong assumption to make; most documents > > don't expire immediately. Of course, that's not say that this isn't the > > right assumption to make sometimes. > > It's a question of perferring to get the right document over the wrong > one. The following scenario: > 1. Someone creates a document in June, 1996. > 2. Your proxy accesses in February, 1998. > 3. The person changes it in March, 1998. > Anyone using your proxy will not see the changes for a whole two months. Again, this is simply not true. The proxy will not cache a document without and Expires header for longer than MaxExpire without checking the origin server. MaxExpire is 12 hours, by default (I think). > This doesn't quite sound like desired behavior to me. And, yes, this isn't > completly hypothetical - I actually do have some web documents that > haven't been updated since 1994, and I'm sure other people do, too. What > if I decide to change them tomorrow? > > While I'm admit that for certain applications, an > always-return-cached-version mode may be desirable, I think that, at > least, there needs to be an option to act as I've described. It does. RTFM. David.