Bug in ap_internal_fast_redirect

Top Page

Reply to this message
Author: Torsten Foertsch
Date:  
To: dev
CC: titetluc titetluc
Subject: Bug in ap_internal_fast_redirect
Hi dev,

on the modperl mailing list we had recently an interesting problem that has
revealed a bug in ap_internal_fast_redirect, see

https://issues.apache.org/bugzilla/show_bug.cgi?id=45297

Suppose this config:

DirectoryIndex index.shtml
Options Includes Indexes
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

<Location /index.shtml>
Require valid-user
AuthType basic
AuthName "Something very secret"
AuthUserFile /path/to/htpasswd
</Location>

and an SSI document or an other handler that uses r->user as index.shtml:

<html>
<body>
<h1>Hello <!--#echo var="REMOTE_USER" --></h1>
</body>
</html>

If called directly as "/index.shtml" r->user is shown correctly. But if called
via mod_dir as "/" the auth basic dialog appears but r->user is empty.

The problem lies in ap_internal_fast_redirect. It simply forgets to copy
r->user from the subrequest.

I have attached a patch to the bug that "solves" the problem.

But ... ap_internal_fast_redirect seems to me like an ugly hack. The name is
very misleading. It pretends that an internal redirect is done but that's not
true. The function simply copies values from a subrequest to the main
request.

It is called with 2 requests and one of them is a subreq and it practically
overwrites the main req with the content of the subreq.

In mod_dir the function is called from the fixup hook when it decides to use a
certain document as DirectoryIndex. A subreq was previously used to check if
the document exists as a regular file.

So I am wondering wouldn't it be better to call ap_run_sub_req(subreq) to put
out the response instead of that hack? I am trying to understand why
ap_internal_fast_redirect is necessary at all?

Thanks,
Torsten