Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <461D535C.4040000@dixon.ukf.net>
Date: Wed, 11 Apr 2007 22:30:04 +0100
From: Adrian Dixon <adrian@dixon.ukf.net>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.8a6) Gecko/20050109
MIME-Version: 1.0
To: users@httpd.apache.org
References: <461CFD96.2000700@dixon.ukf.net>
 <e498c1660704111155o68b4a945m4f3fc93b1e7021ec@mail.gmail.com>
In-Reply-To: <e498c1660704111155o68b4a945m4f3fc93b1e7021ec@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [users@httpd] action causes unexpected extra redirection

Joshua Slive wrote:

> On 4/11/07, Adrian Dixon <adrian@dixon.ukf.net> wrote:
>
>> Using an action directive from the mod_actions module in Apache httpd
>> 2.2.4 installations seems to cause two actions rather than just the
>> expected one. In the rewrite log with a log level of 9, there is a
>> report of a second redirection to a path composed of the action path
>> concatenated with the original path (all relative to the document root).
>> When redirection is also in effect, this can cause many extra
>> redirection requests to appear in the rewrite log. I have not attempted
>> to check the behaviour in earlier httpd versions.
>
>
> I really don't understand what problem you are having. Apache
> frequently uses "internal redirects" or subrequests to serve files.
> This is a relatively light-weight operation and shouldn't be a concern
> to anyone not on the absolute bleeding edge of performance
> requirements for static file-serving. Passing the original path on as
> PATH_INFO on the subrequest also seems completely expected.
>
> Joshua.
>
Joshua, thanks for the information. It's useful to know these are 
light-weight. As you say, it is clearly correct and expected to receive 
the original request as PATH_INFO and the resolved source as SCRIPT_NAME 
in the intended action. I was trying to summarise the construction of 
the resolved source of the (surprising to me) second subrequest. 
Obviously clumsily.

The original difficulty I had was finding the rewrite log confusing, 
especially when using combinations of modules. Instead of the one 
request resolution sequence I anticipated, I found a cascade of subrequests.

What I am trying to do is, in a multilingual service using url rewriting 
to support name-based virtual hosts, use the presence of file name 
extensions to trigger interception of requests by actions. The idea is 
that if specific extensions are not present in a filename resolved by 
mod_negotiation, the file is served directly, but that if a specific 
extension is present, the serving of the file is moderated by a generic 
action. That way, Apache is efficient in delivering files that do not 
need such actions.

I have been unsuccessful in getting mod_rewrite directives in the main 
config files to notice the file extensions in files discovered by 
mod_negotiation, but was pleased to find the action directive of 
mod_actions responded to the fully resolved filename. Unfortunately, the 
action directive only affects the script name within the virtual 
document root, and I want the actions to be generic, and outside of both 
URL space and directories for the virtual hosts. When I noticed that 
action cgi-script values beginning without an initial slash were 
recognised as such by mod_rewrite, I thought I had succeeded. They could 
not be duplicated by external requests, so mod_rewrite could map them to 
standard files above all virtual document roots in the hierarchy. OK - I 
admit it's a hack, but it seemed such a nice hack, until I hit those 
extra "internal redirects". They are processed with the initial slash 
firmly back in place, so they land right back in the virtual host 
spaces, and trigger rewriting activity and further actions - none of 
which seem to be related to delivering the result I want. I suspect it 
is only the anti-looping test in mod_actions that prevents disaster.

I did the simple tests hoping they would show the behaviour was caused 
by something else in my configuration. Sadly, not.

With further work, I might be able to catch and cancel the behaviour I 
do not want earlier, so that virtual host spaces are not compromised. My 
attempts so far have failed. However, if I am simply doing something  
wrong - eg. in compilation - that triggers the behaviour, it would be 
better if I stopped doing that wrong thing. Conversely, if the behaviour 
is normal but actually useless, maybe it can be removed in a future 
version of Apache httpd. A guy can dream.

Adrian

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org