You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2002/03/13 18:27:47 UTC
ap_sub_req_lookup_dirent
What is the purpose of calling ap_process_request_internal() in
ap_sub_req_lookup_dirent()?
Bill
Re: MS VS .NET errors with current CVS
Posted by Jobarr <jo...@herzeleid.com>.
> The Apache group only uses v6 of MSVC.
Oh alright. I just got a copy of it for free at a MS VS . NET Academic
launch last night so I figured I'd try it out :)
> the simple fix for you is to add the new file nt_eventlog.c
> into the ilbhttpd project under the mpm_winnt folder
Thanks, that fixed that error!
-Jobarr
Re: MS VS .NET errors with current CVS
Posted by Ian Holsman <ia...@apache.org>.
Jobarr wrote:
> I don't know if these are just errors from Visual Studio .NET or if they are
> because it's CVS source. Either way, just figured you guys might want to
> know
hi.
The Apache group only uses v6 of MSVC.
the simple fix for you is to add the new file nt_eventlog.c
into the ilbhttpd project under the mpm_winnt folder
Thanks
Ian
> -Jobarr
>
>
> Creating library .\Release/libhttpd.lib and object .\Release/libhttpd.exp
> service.obj : error LNK2019: unresolved external symbol
> _mpm_nt_eventlog_stderr_flush referenced in function _service_stopped
> service.obj : error LNK2019: unresolved external symbol
> _mpm_nt_eventlog_stderr_open referenced in function _mpm_service_to_start
> .\Release/libhttpd.dll : fatal error LNK1120: 2 unresolved externals
> Build log was saved at "file://d:\source\httpd-2.0\Release\BuildLog.htm"
> libhttpd - 3 error(s), 3 warning(s)
>
> ...
>
> copy Release\libhttpd.dll "\Apache2\bin" <.y
> The system cannot find the file specified.
> NMAKE : fatal error U1077: 'copy' : return code '0x1'
> Stop.
> Project : error PRJ0019: A tool returned an error code: "Performing Makefile
> project actions"
> Build log was saved at "file://d:\source\httpd-2.0\Release\BuildLog.htm"
> InstallBin - 2 error(s), 0 warning(s)
>
MS VS .NET errors with current CVS
Posted by Jobarr <jo...@herzeleid.com>.
I don't know if these are just errors from Visual Studio .NET or if they are
because it's CVS source. Either way, just figured you guys might want to
know
-Jobarr
Creating library .\Release/libhttpd.lib and object .\Release/libhttpd.exp
service.obj : error LNK2019: unresolved external symbol
_mpm_nt_eventlog_stderr_flush referenced in function _service_stopped
service.obj : error LNK2019: unresolved external symbol
_mpm_nt_eventlog_stderr_open referenced in function _mpm_service_to_start
.\Release/libhttpd.dll : fatal error LNK1120: 2 unresolved externals
Build log was saved at "file://d:\source\httpd-2.0\Release\BuildLog.htm"
libhttpd - 3 error(s), 3 warning(s)
...
copy Release\libhttpd.dll "\Apache2\bin" <.y
The system cannot find the file specified.
NMAKE : fatal error U1077: 'copy' : return code '0x1'
Stop.
Project : error PRJ0019: A tool returned an error code: "Performing Makefile
project actions"
Build log was saved at "file://d:\source\httpd-2.0\Release\BuildLog.htm"
InstallBin - 2 error(s), 0 warning(s)
Re: ap_sub_req_lookup_dirent
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
> >
> >
Re: ap_sub_req_lookup_dirent
Posted by Bill Stoddard <bi...@wstoddard.com>.
> >
> > 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
>
I think the problem may be with the location of the quick_handler hook. Or we need to be
more selective in when we call quick_handler(). Ian (I think) moved the location in order
to be able to search the cache for SSI include files (that are fetched via subrequests).
Will need similar function for Akamai ESI tag handling... Need to mull this over a bit...
Bill
Re: ap_sub_req_lookup_dirent
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > 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
Posted by Ryan Bloom <rb...@covalent.net>.
> 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
Posted by Bill Stoddard <bi...@wstoddard.com>.
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
Posted by Ryan Bloom <rb...@covalent.net>.
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