Jim Jagielski [Sat, 16 Jan 1999 22:00:46 +0000 (22:00 +0000)]
Take II of the shell consistancy change. Although I agree that the use
of '.' is easier on the eyes, 'x' does seem more common and old-dog
shell programmers kind of expect it. It's also easier to search for in
vi :)
Some may question why we need to wrap or protect if we are sure that
the $var isn't null, but it really doesn't cost that much for the
extra insurance and it stops people from having to shift "mental gears"
when they run across such statements.
Some may question why even bother with a consistant style... I think
it's important to write readable code and understandable code and code
that others can maintain easily. A consistant style, IMO, helps this
effort. It also just plain looks better :)
PR:
Obtained from:
Submitted by:
Reviewed by:
brian [Fri, 15 Jan 1999 00:57:10 +0000 (00:57 +0000)]
This is the document on how to use mod_rewrite to eliminate the need for
virtualhost settings in the config file. Many thanks to Tony Finch <dot@dotat.at>
for contributing this!
pcs [Sat, 9 Jan 1999 16:53:56 +0000 (16:53 +0000)]
Try to avoid some confusion from the changing of command line arguments,
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.
Small fix for mod_env.html: The module was documented as to be _not_
compiled into Apache per default, although it _IS_ compiled into
Apache per default.
Two minor enhancements to mod_rewrite: First RewriteRule now also supports the
``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
Fix a few minor inconsistencies related to directive scoping
============================================================
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):
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:
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:
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 ;-)...
Cleanup the command line options: `-?' was documented to show the usage list
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
dgaudet [Sun, 13 Dec 1998 20:42:16 +0000 (20:42 +0000)]
update the draft-ietf-http-connection-00 link... this new link works... but
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:
pcs [Fri, 4 Dec 1998 17:37:06 +0000 (17:37 +0000)]
Fix negotiation so that we prefer an encoded variant over an unencoded
variant if the user-agent explicitly says it can accept that encoding.
Previously we always preferred the unencoded variant.
PR: 3447
Submitted by: Paul Ausbeck <paula@alumni.cse.ucsc.edu>
Reviewed by: Paul Sutton
pcs [Fri, 20 Nov 1998 16:39:03 +0000 (16:39 +0000)]
Make documentation clearer for Windows users: state when descriptions
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).
pcs [Fri, 20 Nov 1998 15:56:34 +0000 (15:56 +0000)]
Add link to description of how files with multiple extensions are
handled. At the same time update the descriptions of the directives
to make the descriptions in the authoritative file (mod/mod_mime.html).
pcs [Fri, 20 Nov 1998 15:45:36 +0000 (15:45 +0000)]
Be more careful when documenting the way that extensions are mapped to
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"
Fix documentation of `Action' directive: It can activate a CGI script when
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
PR: 2706
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.
Marc Slemko [Wed, 21 Oct 1998 05:57:58 +0000 (05:57 +0000)]
Add a "default-handler" handler that calls the default_hander()
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.
Marc Slemko [Mon, 19 Oct 1998 04:59:36 +0000 (04:59 +0000)]
Since this entry was based on a small number of reports some time ago
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.
Martin Kraemer [Tue, 6 Oct 1998 19:54:01 +0000 (19:54 +0000)]
Add the new mod_autoindex features to new_features_1_3, add hyperlinks to
the IndexOptions keyword arguments (in the new form HREF="#indexoption:keyword").
Ken Coar [Fri, 2 Oct 1998 21:35:33 +0000 (21:35 +0000)]
Back off a portion of the incremental-IndexOptions patch;
unprefixed keywords should clear all inherited options and
start setting the local directory's options from scratch.
Otherwise, 'keyword' and '+keyword' are essentially identical,
and clearing inheritance a pain.
Ken Coar [Mon, 28 Sep 1998 22:32:10 +0000 (22:32 +0000)]
There appear to be no dissenters (other than for brand-new and
incompatible syntaxes) after three days, and I want to get this
in for 1.3.3. It can always be modified or reverted later.
Add +/- prefixes to IndexOptions keywords, allow merging of
multiple occurrences, and document the changes.
Ken Coar [Thu, 17 Sep 1998 14:52:03 +0000 (14:52 +0000)]
Some more consistency (cgi -> CGI) fixes, and shortened long lines.
(There are about 200 more >80 lines in the dos, but I haven't the
time now to fix 'em. Oh well.)
Martin Kraemer [Tue, 8 Sep 1998 21:15:53 +0000 (21:15 +0000)]
Sameer posted the AllowCONNECT back in march. I adapted it to default
to ports 443 and 563 (for https:// and snews://) and wrote a description
for the mod_proxy.html document.
Marc Slemko [Fri, 4 Sep 1998 18:15:45 +0000 (18:15 +0000)]
Fix mod_expires to add Expires headers for content that isn't served
from disk (ie. the case where r->finfo.st_mode == 0), unless it is
a modification date based setting.
PR:
Obtained from:
Submitted by: Paul Phillips <paulp@go2net.com>
Reviewed by:
Ken Coar [Wed, 2 Sep 1998 21:04:39 +0000 (21:04 +0000)]
Update the filname column width-sizing piece of mod_autoindex
so that it's customisable with a NameLength keyword on the
IndexOptions directive. A value of '*' means 'as wide as the
longest filename,' which was the default effect of the last
patch in this area.
Ken Coar [Mon, 31 Aug 1998 01:18:48 +0000 (01:18 +0000)]
Clean up mod_autoindex's storage of the IndexOptions settings.
They are per-directory, not per-filename, so keeping them in
an array is confusing and pointless. They're now stored in an
int in the module config record. Also (finally!) fix the
FancyIndexing directive so it gets merged into any IndexOptions
settings for the current directory, rather than replacing them.
Martin Kraemer [Sun, 16 Aug 1998 20:51:52 +0000 (20:51 +0000)]
Add proxy Via: header management. Currently, Via: headers can be left
unchanged (compatibility), can be set to protocol and host only,
or to protocol, host and comment. Optionally, all Via: headers can
be suppressed if intranet privacy in companies is desired when going out
over a firewall apache.
Link DSO modules against possible libraries from $(LIBS) (take 2)
=================================================================
Currently we have the following entry in our dso.html document:
| Because DSO modules cannot be linked against other DSO-based libraries (ld
| -lfoo) on all platforms (for instance a.out-based platforms usually don't
| provide this functionality while ELF-based platforms do) you cannot use the
| DSO mechanism for all types of modules. Or in other words, modules compiled as
| DSO files are restricted to only use symbols from the Apache core, from the C
| library (libc) and all other dynamic or static libraries used by the Apache
| core, or from static library archives (libfoo.a) containing position
| independend code. The only chance to use other code is to either make sure the
| Apache core itself already contains a reference to it or loading the code
| yourself via dlopen().
The important part here is: "cannot be linked .... on all platforms". But
there _are_ platform (especially ELF-based ones) which support linking DSO
files agains other DSO files. And even on platforms where this is not
possible is it possible to at least link against libraries assuming they
contain PIC code.
So, the idea is this: In the configuration process we already determine the
variable LDFLAGS and LIBS. They hold -L and -l options for linking
executables. We parse these options and separate them into three classes:
OBJ, PIC and DSO. And then we re-assemble a LIBS_SHLIB variable from only the
options in classes PIC and DSO. This variable is then used on the build
command for mod_xxx.so.
Without SHARED_CORE the mod_auth_db.so cannot be linked or at least not loaded
correctly under run-time. With SHARED_CHAIN enabled it is linked against the
libdb.so and all is fine (at least under this ELF-based Debian box I tried):
This way we provide the maximum we can provide. Sure, on some platforms the
user still has no chance. But this shouldn't mean he becomes no chance on
other platforms where there _is_ a chance. So this patch is a first step for
more friendly and flexible DSO support.
The complete mechanism is triggered by a new Rule named SHARED_CHAIN. To avoid
problems this is DISABLED(!) for ALL(!) platforms currently. But when
experience shows that it worked fine for users we can enable it for tested
platforms per default.
projects / apache / log