Bug 40541 - Action rewrites URI used by Location?
Summary: Action rewrites URI used by Location?
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_actions (show other bugs)
Version: 2.0.52
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2006-09-19 12:55 UTC by Andy Buckley
Modified: 2018-11-07 21:09 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Buckley 2006-09-19 12:55:21 UTC
I'm using a couple of scripts to do pre-processing of files with
certain file extensions and then wrapping the output in a
SetOutputFilter chosen according to the URL. Example:

## ReStructuredText handler
ScriptAlias /test-cgi-bin/ /cedar/testlocal/cgi-bin/
Action rst-handler /test-cgi-bin/rst-filter
AddHandler rst-handler .rst

## /foo contains .rst files
<Location /foo>
  SetOutputFilter blah

This seems not to work: the RST handler processes the RST into HTML
nicely but then the location isn't matched, because the handler changes
the URI (I'm not sure which variable gets read to do this). I can fix
it for this example by adding this:

<Location /test-cgi-bin>
  SetOutputFilter blah

but this is pretty ugly and probably not flexible enough for me in
general. Is this really intentional, and if so is there a work-around?
Comment 1 Joshua Slive 2006-09-19 19:06:07 UTC
1. Quite an old version.

2. You should be using <Directory /full/path/to/foo> in place of <Location /foo>
since you are dealing with the filesystem.

3. Action often has weird effects.  I usually prefer something more like
ScriptAliasMatch (.*\.rst)$ /cedar/testlocal/cgi-bin/rst-filter/$1

But there still could be a bug here; I'm not sure.
Comment 2 Andy Buckley 2006-09-21 10:40:36 UTC
1. Yes - a consequence of having to use packaged versions of Apache 2 from Linux
distributions. I'd rather be on 2.2, but it doesn't seem to be a priority for
packagers :(

2. This is arguably true, although I think the distinction is a bit blurred. I'm
trying to make a filetype be handled the same way for various bits of URL-space,
which may in fact be distributed across areas on the physical filesystem, so
doing it by Directory would be less robust against changes of the filesystem
organisation and would involve a lot of duplication. I think Location is a
neater solution in this case --- and in a lot of cases other than when
specifying file access criteria.

3. This would involve re-writing the script, and since this is meant to handle
e.g. RST files the same way across several virtual hosts, I'm not sure that can
be done in a generic way: i.e. without having to hard-code some mapping from
host names to filesystem path prefix. Yuck. Using an Action has the benefit of
(at least in principle) handling a file the same way regardless of its location.
Or that's my understanding of it, anyway :)

I'm not sure if there's a bug, either, but re-writing the string that Location
does its path matching against was very surprising to me: I would expect a
Location to match the URL by which the file was accessed rather than the path
corresponding to its internal handler.
Comment 3 Andy Buckley 2006-12-15 08:58:57 UTC
Making an Action which prints out the current environment gives these
environment variables (among others, of course) for a test URL of
http://test.insectnation.org/test.ex :


As above, I can successfully apply output filters to this script by a <Location>
applying to /test-cgi-bin, but not one which applies to /handler (which seems
more useful to me). If the environment is being used to determine the
application of <Location>, then the only variable which gets rewritten to point
at /test-cgi-bin is SCRIPT_NAME. I'd expect something like REQUEST_URI (or maybe
REDIRECT_URI) to be used instead (i.e. applying <Location> by request rather
than by whatever internal script handles it) ... any comments on this?
Comment 4 William A. Rowe Jr. 2018-11-07 21:09:56 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.