Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 35399 invoked by uid 500); 26 Oct 2000 22:06:15 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 35387 invoked from network); 26 Oct 2000 22:06:15 -0000 Date: Fri, 27 Oct 2000 00:06:13 +0200 From: Thomas Wouters To: Koen Holtman Cc: new-httpd@apache.org Subject: Re: ETags & NFS caches (Apache 1.3) Message-ID: <20001027000613.Q12812@xs4all.nl> References: <20001026224302.P12812@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from koen@hep.caltech.edu on Thu, Oct 26, 2000 at 02:02:45PM -0700 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Thu, Oct 26, 2000 at 02:02:45PM -0700, Koen Holtman wrote: > I recall having an exchange about strong etags based on the unix ctime vs. > NFS on the http-wg mailing list. Jeff Mogul, who is some kind of NFS guru > in another life, told me that NFS makes no hard guarantees about file > ctimes always changing as soon as the contents change. So this seems to > be an NFS 'feature' not accounted for by Apache. Yeah, I have some vague recollections regarding that as well. Something like data being cached, but not meta-data/file-properties. > This does not explain your observation that it is apache-specific though. Exactly. The only thing we could think of was an OS level cache bug that only gets triggered on extreme use. By the way, I forgot to mention, but we aren't using anything like mod_mmap or some such. The only non-default module is mod_php4, and that isn't used by those pages. > The HTTP-level fix of course is for Apache to make etags weak if the ctime > is less than N seconds ago, for some value of N. Don't ask me what N is. Well, a couple of minutes would work, probably. I hadn't thought of that. I think I'll do a quick hack to see if that works -- the actual change is quite small, since make_etag already creates a weak etag if the difference between request-time and last-modified is less than a second. I guess I'll just do it and see if this works. I'm not sure howmany browsers actually use ETags and respect weak ones, but I'm hoping both Netscape and IE choose to be on the safe side, so it might very well solve 99% of the problem for us. Thanx ! :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!