httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server request.c
Date Tue, 09 Oct 2001 18:41:31 GMT
I'm still not clear here... Greg, would you please provide more details before
I either a) back out a potentially good patch or b) apply the same wrong patch 
to file_lookup?  I need some details of what you were attempting to accomplish,
we don't have the rules straighened out yet, but file_lookup is definately the
other side of this problem.

Can you offer a simple scenario and the config to reproduce it?

We may have to simply surrender and offer that 'all (dirent/file) subrequests
bypass location_walk testing, so they aren't subject to an <Location > limits.'

Bill

----- Original Message ----- 
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
Sent: Monday, October 08, 2001 9:15 PM
Subject: Re: cvs commit: httpd-2.0/server request.c


> I understand this from the perspective of file subrequests, which you did
> not patch; but I'm not so clear on which invalid URIs you are referring to
> here... would you mind explaining further, or cite an example?
> 
> Dirent lookups should be generally following the request cycle, so should file
> lookups, if they are in the same directory as the parent/main request.
> 
> Bill
> 
> ----- Original Message ----- 
> From: <gregames@apache.org>
> To: <httpd-2.0-cvs@apache.org>
> Sent: Monday, October 08, 2001 8:33 PM
> Subject: cvs commit: httpd-2.0/server request.c
> 
> 
> > gregames    01/10/08 18:33:48
> > 
> >   Modified:    server   request.c
> >   Log:
> >   prevent near infinite subrequest recursion with mod_negotiation enabled.
> >   This can happen if there is a partial match between a bad URI and a
> >   file with a variant extention.
> >   
> >   ap_sub_req_lookup_dirent has apparently been generating bogus subrequest
> >   URIs for ages, but they used to be ignored.  Once we started calling
> >   ap_process_request_internal for all subrequests, they started causing
> >   problems.  Make it explicit that rnew->uri is to be ignored for this type
> >   of subrequest.
> >   
> >   Revision  Changes    Path
> >   1.68      +1 -5      httpd-2.0/server/request.c
> >   
> >   Index: request.c
> >   ===================================================================
> >   RCS file: /home/cvs/httpd-2.0/server/request.c,v
> >   retrieving revision 1.67
> >   retrieving revision 1.68
> >   diff -u -r1.67 -r1.68
> >   --- request.c 2001/10/08 22:07:32 1.67
> >   +++ request.c 2001/10/09 01:33:48 1.68
> >   @@ -1345,7 +1345,6 @@
> >        request_rec *rnew;
> >        int res;
> >        char *fdir;
> >   -    char *udir;
> >    
> >        rnew = make_sub_request(r);
> >        fill_in_sub_req_vars(rnew, r, next_filter);
> >   @@ -1363,15 +1362,12 @@
> >         * not even have to redo access checks.
> >         */
> >    
> >   -    udir = ap_make_dirstr_parent(rnew->pool, r->uri);
> >   -
> >        /* This is 100% safe, since dirent->name just came from the filesystem
*/
> >   -    rnew->uri = ap_make_full_path(rnew->pool, udir, dirent->name);
> >        rnew->filename = ap_make_full_path(rnew->pool, fdir, dirent->name);
> >        if (r->canonical_filename == r->filename)
> >            rnew->canonical_filename = rnew->filename;
> >        
> >   -    ap_parse_uri(rnew, rnew->uri);    /* fill in parsed_uri values */
> >   +    rnew->uri = apr_pstrdup(rnew->pool, "");
> >    
> >        /* Preserve the apr_stat results, and perhaps we also tag that
> >         * symlinks were tested and/or found for r->filename.  
> >   
> >   
> >   
> > 
> 
> 



Mime
View raw message