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 </Location> 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 </Location> 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?
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.
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.
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 : HTTP_HOST=test.insectnation.org SCRIPT_FILENAME=/www/test/cgi/testhandler REQUEST_URI=/handler/test.ex SCRIPT_NAME=/test-cgi-bin/testhandler PATH_INFO=/handler/test.ex PATH_TRANSLATED=/www/test/handler/test.ex SERVER_NAME=test.insectnation.org REDIRECT_URL=/handler/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?
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.