Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 64729 invoked by uid 500); 24 Aug 2001 05:13:00 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 64676 invoked from network); 24 Aug 2001 05:12:59 -0000 X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Fri, 24 Aug 2001 01:12:52 -0400 (EDT) From: Cliff Woolley X-X-Sender: To: Subject: Re: mod_include recursive include checking bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 1188 On Fri, 24 Aug 2001, Cliff Woolley wrote: > if (strncmp(rnew->filename, fdir, fdirlen) != 0 > && rnew->filename[fdirlen] > && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL) > > This is not new behavior ... it's been around since rev 1.1 of request.c. Actually, upon further investiation I see that it IS new behavior. rnew->uri was always set to that string, but the condition changed in rev 1.25 of request.c earlier today. Obviously the else case is now getting called more frequently now... is that expected? --Cliff -------------------------------------------------------------- Cliff Woolley cliffwoolley@yahoo.com Charlottesville, VA