You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2002/06/21 19:39:51 UTC

RE: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Saturday, June 22, 2002 9:45 AM
> To: dev@httpd.apache.org
> Subject: Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c
mod_cgid.c
> 
> Looking for both faults (passing the next filter when we are doing
> lookups,
> and passing NULL when we are going to serve the content) ... it really
> seems that;
> 
> D:\clean\httpd-2.0\modules\mappers\mod_negotiation.c(2550):
>          sub_req = ap_sub_req_lookup_file(variant->file_name, r,
NULL);
> 
> SHOULD be setting the next filter.  Anyone want to dig on this?

I am missing something.  The third argument has nothing to do with
whether the request will be served.  It has to do with how the filter
stack is initialized in the sub-request.  If the argument is NULL, the
sub-requests filters are set to the protocol filters of the original
request.  If the argument isn't NULL, then the sub-request's filters are
initialized to the filter passed in.  In either case, the data can
either be sent or not.

Please revert the doc portions of your last change, they are incorrect.
The code is safe to leave, because the requests aren't actually served.
However, mod_negotiation is 100% correct, and should NOT be changed.

Ryan

> 
> Bill
> 
> >wrowe       2002/06/22 09:32:45
> >
> >   Modified:    include  http_request.h
> >                modules/generators mod_cgi.c mod_cgid.c
> >   Log:
> >     Note the changed meaning of the NULL next_filter argument to the
> >     ap_sub_req_lookup() family, and fix a few oddball cases (those
are,
> >     PATH_TRANSLATED reference issues.)
>