Joshua Slive wrote:
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.On 4/11/07, Adrian Dixon <adrian@xxxxxxxxxxxxx> 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.
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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|