Here's a little patch to correct an omission that seems to cause
occasional confusion: Context: Directory actually means Context:
Directory, Location, Files except for specific exceptions.
Obtained from:
Submitted by: Joshua Slive <slive@finance.commerce.ubc.ca>
Reviewed by: dirkx
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83574 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Tony Finch <fanf@demon.net>
Reviewed by: Dean, Randy, Jim, Lars, Martin
Obtained from:
Add the new mod_vhost_alias.c modules for better mass-hosting. This
has been used at Demon Internet with excellent results and basically
replaces the "old" method of using mod_rewrite. Big advantage is
that adding new vhosts can be done without restarting the server.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83357 13f79535-47bb-0310-9956-ffa450edef68
Obtained from:
Submitted by: Mathijs Maassen <mathijs@xs4all.nl>
Reviewed by: Jim, Lars
Add the new DocumentRootCheck directive. This determines if we
check for each DocumentRoot during startup.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83325 13f79535-47bb-0310-9956-ffa450edef68
features use subrequests. Not only that, but they can be
parsed for SSIs too!
PR: 1574, 3026, 3529, 3569, 4256
Submitted by: Raymond S Brand <rsbx@rsbx.net>
Reviewed by: Ken Coar
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83202 13f79535-47bb-0310-9956-ffa450edef68
same extension, the last one encountered dominates. This is
true of lots of directives, but this is the one on which we
got a PR..
PR: 3570
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83135 13f79535-47bb-0310-9956-ffa450edef68
available to CGIs and SSIs within the directive's scope. NOT
recommended for general use, but eases the transition for IBM's
current LDGW customers to Apache.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82956 13f79535-47bb-0310-9956-ffa450edef68
Get rid of the array for the 'env=' clause, since it only takes
a single variable name; use a char * instead. Check for conditional
envars by seeing if the condition string is non-NULL rather than
using a separate Boolean cell.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82826 13f79535-47bb-0310-9956-ffa450edef68
Also add RefererIgnore functionality from mod_log_referer to
mod_log_config; mod_log_referer and mod_log_agent are now
deprecated. The list of envariables to check is set up as
an array even though the current implementation (TAKE23)
only handles one; just in case we ever want to do something
strange like, 'env=foo,bar,!bag'.
PR: 519, 548, 1351, 1811(?), 3449
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82819 13f79535-47bb-0310-9956-ffa450edef68
the user to assign authentication control to any HTTP method that
is *not* given in the argument list; i.e., the logical negation
of the <Limit> directive. This is particularly useful for controlling
access on methods unknown to the Apache core, but perhaps known by
some module or CGI script.
Submitted by: Roy Fielding and Tony Finch <dot@dotat.at>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82783 13f79535-47bb-0310-9956-ffa450edef68
``nocase|NC'' flag (as RewriteCond already does for ages) to match case
insensitive (this especially avoids nasty patterns like `[tT][eE][sS][tT]').
Second two additional internal map functions `escape' and `unescape' were
added which can be used to escape/unescape to/from hex-encodings in URLs parts
(this is especially useful in combination with map lookups).
Submitted by: Magnus Bodin, Ian Kallen
Integrated and fixed by: Ralf S. Engelschall
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82563 13f79535-47bb-0310-9956-ffa450edef68
============================================================
1. httpd -h
Under "httpd -h" one gets a nice English description in which scope a
directive can occur. But we talk here only about <Directory> and <Location>,
although <Files> is treated the same (also with `cmd->override ==
ACCESS_CONF|OR_ALL'). So I think it's correct to also list <Files>, too.
2. Used scope variants
Currently we have 203 directives and they use the following scopes (the
numbers in parenthesis gives the number of directives using a particular
scope):
RSRC_CONF (106)
RSRC_CONF|ACCESS_CONF (5)
RSRC_CONF|ACCESS_CONF|OR_ALL (1) <--
RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2) <--
ACCESS_CONF (5)
OR_AUTHCFG (20)
OR_LIMIT (3)
OR_OPTIONS (4)
OR_FILEINFO (21)
OR_INDEXES (23)
OR_ALL (13)
This is well spreaded and sounds reasonable. Except for
the two classes:
RSRC_CONF|ACCESS_CONF|OR_ALL (1)
RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2)
The first one is just a syntax overkill. It means only OR_ALL, because OR_ALL
includes (implicitly) already RSRC_CONF and ACCESS_CONF. So, when we fix
this to OR_ALL we get:
RSRC_CONF (106)
RSRC_CONF|ACCESS_CONF (5)
RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2) <--
ACCESS_CONF (5)
OR_AUTHCFG (20)
OR_LIMIT (3)
OR_OPTIONS (4)
OR_FILEINFO (21)
OR_INDEXES (23)
OR_ALL (14)
The remaining RSRC_CONF|ACCESS_CONF|OR_AUTHCFG is used by two directives:
UseCanonicalName and ContentDigest. Two not too old directives which were
added mostly at the same time. They're are implemented the same way.
But the scope looks incorrect. Why?
First, it's again syntax overkill, ok. We can reduce it to
RSRC_CONF|OR_AUTHCFG. But when we compare it to all other used scopes, it
looks very inconsistent. No other of the 203 directives want to be applicable
in such a non-orthoginal scope: on the first hand inside the AuthConfig scope
(which means .htaccess under "AllowOverride AuthConfig" plus _INSIDE_ of
<Directory>/<Location>/<Files> sections in httpd.conf only) and on the other
hand also in RSRC_CONF (which means _OUTSIDE_ of
<Directory>/<Location>/<Files> sections in httpd.conf only). Sure, finally
it's everywhere in httpd.conf plus .htaccess under AuthConfig scope. But it's
not intuitive: Directives which want to be applicable in such a total scope
use OR_OPTIONS, OR_FILEINFO or OR_INDEXES. And when we think about
UseCanonicalName and ContentDigest we find out that they belongs more to
Options, XBitHack and CheckSpelling than to any AuthXXXX directives.
So, I propose to change the scope of those two directives to OR_OPTIONS. It
makes no big difference, of course. It still is useable everwhere inside
httpd.conf, but inside .htaccess now under Options instead of AuthConfig. And
it both belongs to the more correct group of directives and makes our list of
used scopes more consistent.
With the above patch be get this consistent scope-list:
RSRC_CONF (106)
RSRC_CONF|ACCESS_CONF (5)
ACCESS_CONF (5)
OR_AUTHCFG (20)
OR_LIMIT (3)
OR_OPTIONS (6)
OR_FILEINFO (21)
OR_INDEXES (23)
OR_ALL (14)
When we take into account that _theoretically_ there are a lot more variants
of these or'ed values are possible, this list is _VERY_ clean. Actually it's
the most clean variant I can think of (except for the fact that the whole
mechanism is a horrible mess ;-)...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82558 13f79535-47bb-0310-9956-ffa450edef68
