2.0.26 request handling - where I am stuck

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Re: 2.0.26 request handling - where I am stuck

["William A. Rowe, Jr." <wr...@covalent.net>]

Comments anyone?

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Monday, September 24, 2001 1:23 PM


> 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.)

*** (if the request r->filename isn't what we already dir/file_walk()ed
     or there was no dir/file_walk at all.)

>    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.

That is, filename has a specific meaning (it's... a file!  yea!)

> *) 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.

It's been a few hours.  I'll go back to mod_win32.c now that Greg Ames'
problem appears to be solved.  Please comment so I can move forward here.

Bill