httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 2.0.26 request handling - where I am stuck
Date Fri, 28 Sep 2001 05:24:37 GMT
Comments anyone?

From: "William A. Rowe, Jr." <>
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.


View raw message