Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <40224E92.20902@modperlcookbook.org>
Date: Thu, 05 Feb 2004 09:09:22 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: FileSystem v.s. Other Resources [was configurable Location?]
References: <4021669F.1060904@apache.org>
 <6.0.2.0.2.20040204163353.0441dec0@pop3.rowe-clan.net>
In-Reply-To: <6.0.2.0.2.20040204163353.0441dec0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> Let's do this in 2.1 by splitting out the file system,
> and if the filesystem module isn't handling a request, it won't be serving
> content but also won't be invoking the directory walk or stat-ing files.

this all sounds kinda interesting, and similar to the way auth has been set
up in 2.1 - more directives and modules, but more flexibility and power.

> 
> Oh last observation - it should become (in 2.1) nearly impossible for folks
> to just bork around with the contents of r->filename and r->finfo, first by 
> stripping them from the request rec, and second by providing an API to
> the filesystem module that lets another module link into another file.
> That API would prevent module authors from bypassing the filesystem
> module's internal security. 

this has come up before, and I'd love to see an API that prevents accidental
disagreement between r->filename and r->finfo (for one).  IIRC, there was
supposed to be some discussion at the hackathon about this, but it sounds
like I didn't miss it :)

--Geoff