ap_sub_req_lookup_dirent
What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
RE: ap_sub_req_lookup_dirent
We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
Re: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
RE: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... We have to run all of the hooks, from translate_name through fixups for all sub-requests. While translate_name shouldn't do anything for a lookup_dirent call, all of the auth hooks, type_checker, and fixups can all modify the request. By calling ap_process_request_internal the code is simplified, because there is only one way to go through request processing. The previous solution had a different path for every subrequest mechanism. Ryan Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
Re: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... We have to run all of the hooks, from translate_name through fixups for all sub-requests. While translate_name shouldn't do anything for a lookup_dirent call, all of the auth hooks, type_checker, and fixups can all modify the request. By calling ap_process_request_internal the code is simplified, because there is only one way to go through request processing. The previous solution had a different path for every subrequest mechanism. Ryan I am not an expert in this area, but it appears that we skip running a lot of the hooks in ap_process_request_internal depending on whether the request is a subrequest or not (and the check for subrequests is very coarse grained, precluding the possibility of selectively handling different subrequests differently. For instance, a dirent subrequest should not call the quick handler ever... perhaps it is okay for other subrequests to call quick_handler... Bill
Re: ap_sub_req_lookup_dirent
Huh? Additional information not already available ??? Try authn/authz, for one. Or, how about Do we have a handler that can handle this resource? Or, 'hmm... Files .bak are never to be served. We must run the entire process_request_internal to know that a file listed in autoindex is servable. If you wanted a toggle for the operator to say, Hey, who cares, give me back the CPU cycle and they can see anything I'm foolish enough to put in those directories!!!, I'd be +1 for such a directive. And skip the lookup altogether. But that's -only- by choice, it should not be the default for the obvious security-related reasons. But you aren't describing anything that fancyindexing on 1.3 didn't already do. No surprise here. Bill At 11:48 AM 3/13/2002, you wrote: ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
