httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: FileSystem v.s. Other Resources [was configurable Location?]
Date Thu, 05 Feb 2004 20:25:15 GMT
At 09:22 AM 2/5/2004, wrote:
>>Effect/Issue 1:
>>Bypassing the filesystem canonicalization would be very bad on certain platforms such
as windows, depending on case sensitivity, etc.  It would
>>also bypass *user configured* options such as avoiding symlinks.
>only for <Location >  If the admin is telling us the content is outside the filesystem,
I don't think filesystem canonicalization or symlinks are relevant.

But the question is how the admin communicates that to us.  You are 
suggesting we allow <Location virtual /not/a/file> to say it's outside of the 
file system.  *However* are you preventing a file from being served?

Guess that is the gist of my concern.

>>Effect/Issue 2:
>>Bypassing the directory block walk would ignore the very <Directory >
>>sections that the user explicitly put in their config.  This too is bad.
>This is only for <Location > .  There is no change to the behavior of <Directory
>>to avoid these consequences, and still save ourselves
>>the pain of the filesystem walk and <Directory > block handling...
>I'm only changing <Location >

Wait - so you say.  But the effect is to disable <Directory > block handling,
am I confused on this point???  If you ignore valid <Directory > blocks because
somewhere else the admin says "Wait - this location is virtual!" then are you
also preventing those files from being served?

If not this is what I suggest is a violation of the principal of least surprise.

>>=== Break out file handling as a separate component ===
>>I've proposed in the past the simple directive
>>FilesystemMount /path/to/files
>At first glance it looks like a key difference is that you are approaching it by saying
that it's OK to have <Location > map to a real filesystem and providing config to explicitly
specify the mapping.  I'm advocating going the other way and allowing <Location > to
be treated as if it is really outside of the filesystem.

Here's what I'm suggesting;

1. Everything in Apache is at some location.  Location is a predictable factor
   because every URI becomes a location.  A Location block will always
   override all other configurations, location blocks are always applied 
   as least-to-most significant if they are absolute, and then pattern matching
   location blocks are applied after that.

2. Some things in Apache are in the Filesystem, some are in JK, some are
   in an application (a cgi with PATH_INFO).  These aren't always 1:1 to the 
   filesystem, except in the case of filesystem-based modules such as our
   default handler and the current cgi modules.

3. If something is in the Filesystem, then <Directory > and <Files > should
   be applied.  If something is not in the filesystem, than no, it should not, and
   that other backend (e.g. proxy) should have it's own container blocks to
   deal with the resource (e.g. <Proxy > blocks.)  Overloading can become
   a very confusing a dangerous game for admins to properly configure their

4. If something is not in the Filesystem, there should be no way that our own
   CGI handler or default file handler should be allowed to handle the request.
   If Apache 

5. Whatever resource (Filesystem or what have you) that claims to own the
   resource for config block processing should be the only available handler
   to deal with the resource on the back end.  Jumping from one resource 
   context in the configuration phase to another resource resource in the
   handler phase is very dangerous.

Beyond what I've detailed above, I'm flexible about how it works/what the various
directives are, etc.


View raw message