Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Sender: gregames@Mail.MeepZor.Com
Message-ID: <3BC317F3.8B7D08B8@remulak.net>
Date: Tue, 09 Oct 2001 11:29:55 -0400
From: Greg Ames <gregames@remulak.net>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0/server request.c
References: <20011009013348.92479.qmail@icarus.apache.org>
 <030a01c15068$dbd27bf0$93c0b0d0@roweclan.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"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 dev@httpd.apache.org 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
http://bugs.apache.org/index/full/3807 from the production server, I get
a valid bug report back as expected, after an external redirect to
bugs.apache.org/index.cgi/full/3807 .

Under the covers, mod_negotiation's type checker to be driven with
r->filename == /www/bugs.apache.org/index , 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/bugs.apache.org/ 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/bugs.apache.org/index.cgi
(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.

Greg