https://bz.apache.org/bugzilla/show_bug.cgi?id=69092
Bug ID: 69092
Summary: Clarify Location for non-filesystem use
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Documentation
Assignee: docs@httpd.apache.org
Reporter: car...@gmail.com
Target Milestone: ---
I would like to request additional clarity to be added to the Configuration
Sections (https://httpd.apache.org/docs/2.4/sections.html) page:
1. The documentation
| The <Location> directive need not have anything to do with the filesystem.
Is not very descriptive for what non-filesystem use it has. As far as I can
tell, there is only documentation for its use with proxies (forward and
reverse) as well as for specific modules to map an endpoint with a handler. Any
other use cases seem to be left to the imagination (with little direction on
how to accomplish anything else).
2. Due to <Directory> applying only to the filesystem, it cannot map to
webspace and only applies to files under DocumentRoot. My conclusion is that
DocumentRoot is specially handled to map the filesystem under it to webspace
and to duplicate the configuration found from <Directory> (as opposed to the
directive being able to configure webspace directly)--in other words it
automatically does #3 below.
3. Documents residing on the filesystem outside DocumentRoot require two steps:
Alias and <Location>. The former maps the filesystem to the webspace and the
latter applies to it the same configuration that would be found in a
<Directory> directive. This approach would be similar to a filesystem symbolic
link, but in webspace, to give the effect of multiple DocumentRoots.
AliasMatch "^/webspace/path/root/" "/filesystem/path/root"
<Location /webspace/path/root/>
</Location>
NOTES:
- This is against the important remark already documented
| It is important to never use <Location> when trying to restrict access to
objects in the filesystem. This is because many different webspace locations
(URLs) could map to the same filesystem location, allowing your restrictions to
be circumvented.
Still, I think it was insightful with regards to the directive behaviours
(and surprising).
- The alternative is to handle multiple DocumentRoots using multiple
<VirtualHost>; however, I see no indication that a second <VirtualHost> is
allowed to have identical configuration (IP, port, hostname, et cetera).
Furthermore, this approach seems like it would be a lot of overhead
configuration for just a single file or two (using Alias instead of
AliasMatch). Admittedly I have not tested this.
- My particular circumstance was the desire to have a PHP script handle two
paths (it processes the URL to determine which path was given):
/webspace/path/parent and /webspace/path/parent/child. The configuration that
worked for me was roughly:
# limit to parent and one level lower
AliasMatch "^/webspace/path/parent/[\w\d_-]+(/|/[\w\d_-]+)?$"
"/filesystem/path/to/app.php"
<Location /webspace/path/parent/>
# Authentication: Basic
AuthName "my name"
AuthType Basic
AuthBasicProvider file
AuthUserFile "filesystem/path/to/.htpasswd"
<RequireAll>
Require valid-user
</RequireAll>
# https://httpd.apache.org/docs/2.4/mod/mod_actions.html#action
Action application/x-httpd-php "/filesystem/path/to/app.php"
</Location>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
