Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <05a501c1834a$61f158f0$93c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
References: <056101c18343$024aab60$93c0b0d0@v505>
 <3C17B8F0.A189F3C9@Golux.Com>
Subject: Re: Considering the Default Handler and Subrequests
Date: Wed, 12 Dec 2001 14:19:55 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Rodent of Unusual Size" <Ken.Coar@Golux.Com>
Sent: Wednesday, December 12, 2001 2:07 PM


> "William A. Rowe, Jr." wrote:
> > 
> > 3. Namespace polution is evil.  Ergo, any module should reject requests
> >    for a document with path_info if it doesn't address the name space
> >    passed in path_info for the request.
> 
> Can you explain this in different words?  And/or maybe an example?

Create a document /somepath that accepts path_info but does nothing with it.

/somepath
/somepath/0
/somepath/1
...
/somepath/9
/somepath/a
/somepath/b
...
/somepath/z
...
/somepath/0/0
/somepath/0/1
... ad infinitum

ALL MAP to /somepath.  As far as any indexing engine is concerned, there are
an infinite discrete number of pages.  This is what makes path_info mappings 
such a problem.

In viewcvs.cgi, we have a discrete number of accepted path_info mappings, all
of which point at specific files of a repository.  There are a number of good
path_info uses in mapping a file-based 'program' to a virtual space, such as
the contents of an archive file, a repository, or so forth.

But if you never use path_info, it should be rejected to prevent exactly this
sort of polution/infinite recursion.

Bill