Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 17744 invoked by uid 6000); 18 Nov 1999 14:57:21 -0000 Received: (qmail 17609 invoked from network); 18 Nov 1999 14:57:03 -0000 Received: from internal.mail.demon.net (193.195.224.3) by taz.hyperreal.org with SMTP; 18 Nov 1999 14:57:03 -0000 Received: from fanf.eng.demon.net (fanf.eng.demon.net [195.11.55.89]) by internal.mail.demon.net with ESMTP id OAA24121; Thu, 18 Nov 1999 14:56:56 GMT Received: from fanf by fanf.eng.demon.net with local (Exim 3.03 #2) id 11oSz0-000Ifz-00 for new-httpd@apache.org; Thu, 18 Nov 1999 14:56:22 +0000 To: new-httpd@apache.org From: Tony Finch Subject: Re: proxy caching is important In-Reply-To: <3833DF10.1F6D76A@sharp.fm> References: Message-Id: Date: Thu, 18 Nov 1999 14:56:22 +0000 Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Graham Leggett wrote: > >The problem of checking the whether cached data has changed on disk can >be handled the same way a normal forward proxy handles it - using data >aging and shift-reload in the browser to force a cache refresh. In the situation where we use reverse proxy caches (an almost-entirely static content server) it's possible to do much better than the usual "guess and hope we aren't too far wrong" approach to cache freshness. We know about all the updates to the content on the server and we have a mechanism for notifying the caches of changes, so when users alter their pages they see the update immediately without having to fiddle with shift-reload (which they find quite tricky). The cacheing mechanism in Apache should aim for that level of service. Tony. -- how to dot at