>I just realised that this is wrong: the %v won't work on 1.3.4 because
>it always uses the canonical server name. It should be changed to
>%{SERVER_NAME}e.
So I've changed it accordingly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82687 13f79535-47bb-0310-9956-ffa450edef68
by documenting the meanings of the arguments for each different version of
Apache. This is important since the current live site now documents the
"new" behaviour (for -L, -l, h) even though there is no released Apache
for which that documentation is valid. Even after releasing 1.3.4 users of
older versions will be accessing the documentation.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82625 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
The same procedure as _every_ year, James!''
So, a lot of touched files here, but it's just a tiny harmless patch.
As every year we bump up the year number in our copyright headers.
1. "199x-1998" => "199x-1999"
2. "1998" => "1998-1999"
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82561 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
but does it with an error because `?' is not a valid command. OTOH a lot of
users expect `-h' to print such a usage list and instead are annoyed for ages
by our huge unreadable list of directives. So we now changed the command line
options this way:
1. `-L' => `-R'
Intent: we need `-L' to be free, and `-R' for the DSO run-time path is
very similar to the popular linker option.
2. `-h' => `-L'
Intent: while -l gives the small list of modules, -L now gives the
large list of directives implemented by these modules. This is also
consistent with -v (short version info) and -V (large version info).
3. `-?' => `-h'
Intent: it's now the expected option ;-)
The manual page was adjusted accordingly.
Submitted by: Ralf S. Engelschall
Reviewed by: Randy Terbush
PR: 2714
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82497 13f79535-47bb-0310-9956-ffa450edef68
I'm still not sure if this draft has issued as an RFC or if it's just fallen
dead
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82480 13f79535-47bb-0310-9956-ffa450edef68
apply only to Unix; add links to Windows and TPF instructions. Where
defaults are different in OS/2 or Windows, show them. Add the -k command
line option (Windows only).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82409 13f79535-47bb-0310-9956-ffa450edef68
handled. At the same time update the descriptions of the directives
to make the descriptions in the authoritative file (mod/mod_mime.html).
PR: 3151
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82405 13f79535-47bb-0310-9956-ffa450edef68
meta data. Note the effect of multiple extensions in all the Add*
directive descriptions, and explain that these directives add or override
existing mappings. Remove assumptions that there is only one extension.
Add note about how setting both handlers and media types could result in
unexpected results. Remove some highly misleading information such as that
the type is the extension left "after content-encoding and language
extensions have been removed"
PR: 3151
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82403 13f79535-47bb-0310-9956-ffa450edef68
either a handler or a MIME content type is triggered by the request. We forgot
to mention the handler-based variant here.
Submitted by: Andrew Pimlott <pimlott@math.harvard.edu>
Reviewed by: Ralf S. Engelschall
PR: 3340
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82398 13f79535-47bb-0310-9956-ffa450edef68
This is a temporary version. I'll update the paths later based
on what we decide regarding the APACI default paths.
(Any native english speaker is welcome to proofread the text. :-))
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82386 13f79535-47bb-0310-9956-ffa450edef68
Changed references to "/status" to "/server-status". This isn't really
necessary, but a user was confused by the difference between the docs and
the configuration file, and consistency is a good thing.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82329 13f79535-47bb-0310-9956-ffa450edef68
function which is normally called for static content. This allows
you to override a specific handler. This is not a complete solution to
being able to "unconfigure" things as asked for in PR#2979, but it is
still useful.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82288 13f79535-47bb-0310-9956-ffa450edef68
and current versions of HP's compiler appear to be fine and I haven't
seen anyone report this in a long time, remove the reference to problems
with HP's compiler.
PR:
Obtained from:
Submitted by: Nathaniel McIntosh <mcintosh@cup.hp.com>
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82274 13f79535-47bb-0310-9956-ffa450edef68
