Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <065701c14526$495203b0$96c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@httpd.apache.org>
Subject: 2.0.26 request handling - where I am stuck
Date: Mon, 24 Sep 2001 13:23:10 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here's the status of my tree.

I've changed my file_walk and dir_walk to create dummy cache records
upon success, that can be tested later.

If r->filename is null, it bypasses both.  If it's not an absolute path,
or an empty string, it bypasses dir_walk, and file_walk tests the name.

Later, it must be captured for security if we serve a file.  As I looked
at this, I realize that this should happen 'up front' in the
ap_internal_process_request() code.  That poses a thorny problem.

First, we -don't- set the default handler today in ap_i_p_r() when 
r->handler is NULL.  And I believe we should, no?

Second, we really -don't- know who is willing to serve the request.
Does default-handler actually consume the request, or is some other
handler about to step up and deal with a non-file, although it never
set the r->handler field?

Finally, we -should- decide by the end of ap_internal_process_request()
that we will, or won't, serve the request.  That way, mod_autoindex and
others won't report bogus, unservable URIs.

We have a couple of options, but I think this is my favorite:

*) Set r->filename to NULL at the end of ap_internal_process_request,
   if r->filename isn't an absolute file name (that was dir_walk'ed.)
   Even modules that trust r->filename to contain a mod_mime-able name 
   (to get content-type, etc) will be happy since mod_mime and friends 
   did their work already by the fixup hook.  If they aren't serving a
   file, this isn't the field to use.

*) If r->handler is NULL, or 'default-handler', and we didn't dir_walk,
   then die at the end of ap_internal_process_request().  Presume any
   *module* willing to put a bogus entry in r->filename is entirely
   prepared to handle it, and will set r->handler.

Well I'll pick your brains for an hour or few before I go forward, I have
code to hack for mod_win32.c to get win32 cgi working with the registry
and shebang line.

Bill