httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: httpd-2.0/server request.c
Date Tue, 09 Oct 2001 15:29:55 GMT
"William A. Rowe, Jr." wrote:
> 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?

Take a look at the thread on entitled "infinite
recursive subrequests".  I have some details there about an invalid URI
that can trigger this bug.

I believe that a valid URI can also cause this problem.  If I request from the production server, I get
a valid bug report back as expected, after an external redirect to .

Under the covers, mod_negotiation's type checker to be driven with
r->filename == /www/ , r->uri == /index/full/3807
.  Notice that the filename has already been trimmed back, and is out of
sync with the original URI.  read_types_multi looks in
/www/ for files starting with "index", finds index.cgi,
decides that it looks promising and calls ap_sub_req_lookup_dirent. 
This function sets rnew->filename = /www/
(fine), and rnew->uri = /index/full/index.html (totally bogus).  

We are running 2.0.24 on the production server, so
ap_sub_req_lookup_dirent does not attempt to drive the full request
cycle by calling ap_process_request_internal.  The subset of the request
cycle that it uses ignores the bogus subrequest URI and keys off of
rnew->filename, so the only harm done is some wasted CPU cycles.

On the current cvs HEAD, we are trying to run a complete request cycle
for dirent subrequests.  ap_process_request_internal will try to use
r->uri if it is non null, which leads to the infinite recursion.  We
have to either do something about the bogus dirent subrequest URIs, or
quit trying to drive ap_process_request_internal.  I chose the former.


View raw message