Since I'm no more active at the Fachschaftsrat Informatik of the University of Saarland anymore, I have transferred all my university time legacy web pages from http://fsinfo.cs.uni-sb.de/~abe/ to this interim host at http://fsinfo.noone.org/~abe/ with only minimal modifications, mainly e-mail addresses.
Most pages on this interim host won't be updated anymore until they are moved (and redirected) step by step to their future home somewhere under http://noone.org/.
Please also note that my former e-mail address
abe@fsinfo.cs.uni-sb.de is
no more valid. Use abe@deuxchevaux.org
instead.
— Axel Beckert, Zürich, 23rd of September 2007
Just another little Apache Tips & Tricks page
The Apache HTTP Daemon is, according to the Netcraft Web Server Survey, the most popular web server software on the world. It's free, modular and runs on a lot of operating systems.
Needless to say, that they're all running Apache HTTPds... ;-)
cip117
, but due to the whole pool
currently is down because of the air-conditioning is
out of order, it moved temporarily to
xcip3
.
I've written several PERL scripts for use with an Apache HTTPd. They can all be downloaded on my software page.
Until now I've only written one patch for the Apache HTTPd. It also can be can found on my software page.
Patch for
configurable text, link and background colors in
directory listings
The patch was written for Apache 1.3.9, but works at
least with all stable Apache version from 1.3.9 to
1.3.19.
This patch is in production mode use on
www.dagstuhl.de
since early 1999 without any problems and therefore
considered stable. Although: This patch is
distributed in the hope that it will be useful, but
without any warranty; without even the
implied warranty of merchantability or
fitness for a particular purpose. (See the
GNU General Public
License for more details.) The patch is free
software; you can redistribute it and/or modify it
under the terms of the
GNU General Public
License as published by the
Free Software
Foundation; either version 2 of the License, or
(at your option) any later version.
This patch gives you five additional configuration commands, which can be used in server-wide configurations files as well as in per-directory configurations files:
HTML_color can be any string you would give to a BODY tag's BGCOLOR, TEXT or LINK parameter.
Have a look at http://www.dagstuhl.de/DATA/ to see an example. The configuration for the colors on that site are:
DirectoryIndexBGColor "#FFFFFF" DirectoryIndexTextColor "#000000" DirectoryIndexLinkColor "#808080" DirectoryIndexVLinkColor "#404040" DirectoryIndexALinkColor "#FF0000"
If you have mod_perl installed into your Apache, you can also use Apache::AutoIndex instead, which has much more features than my small patch, but sometimes has strange problems with some other mod_perl modules like Embperl.
I always keep here an global copy of a well done dynamic directory listing (mod_autoindex) configuration, MIME types and magic file. The MIME types configuration is heavily expanded and only few original entries are modified. The magic file is mainly based on the KMimeMagic magic file, which can be seen as an more actual and heavily enlarged version of the Apache magic file, which seems to be based on that from file(1). It's updated according to new mime-types and has no more missing tabs in it.
.img
,
which I use for image type maps. Replace it by an
appropriate suffix which fits for your site.
My sources for the MIME types and the appropriate file suffixes can be found in my bookmarks under the subject MIME. For some single entries the information about correct MIME types comes from the documentation of the document format, e.g. like in the cases of PNG, MNG and JNG, see my bookmarks under the subject Graphics
Here you'll find some of my own tips & tricks for configuring and administrating the Apache HTTPd. Maybe this page will become bigger some day...
For German users: I've got those rules actually swapped out in a file
called dau.conf
... ;-)
Inexperienced people, reading handwritten or badly printed URLs often misinterpret the "~" character.
You may think, it is just my fantasy that people may mix up those characters. It isn't. Here is what I discovered in our logs at Dagstuhl: People really tried to get user pages by typing "''", "``", "-", "`" or '"' instead of "~"! Except the "`", I guess, all were misinterpretations of the character "~". "`" was probably a typo, because at least US-English keyboard layouts, you'll get a "`", if you try to type a "~" without pressing a shift or caps lock key before.
Typos are mostly regcognized by the people themselves, but IMHO it's nice not to let them notice, that they made a typo. And configuring this problem for a few more typos isn't a big hack if we just started for those people who can't read URLs correctly. I think the following typos may appear quite often:
Due to Apache cannot do spelling correction on user names or directories, it's sometimes necessary to lend him a hand... I've got two solutions for this:
An easier RedirectMatch
command...
RedirectMatch permanent ^/([-¸·{|}´`'"+*^¯¨¬\\]|''|``|\^\^)(.*)$ http://www.domain.com/~$2
... and more complex, but much better set of
RewriteRule
s (needs
mod_rewrite):
# Part a: URL does not end with "/" RewriteCond /var/htdocs/$1$2 !-d RewriteCond /var/htdocs/$1$2 !-f RewriteCond /~$2 -U RewriteRule ^/([-¸·{|}´`'"+*^¯¨¬\\]|''|``|\^\^)(/?([^/]+)(/.*[^/])?)?$ http://www.domain.com/~$2 [R=permanent,L] # Part b: URL ends with "/" RewriteCond /var/htdocs/$1$2 !-d RewriteCond /~$2 -U RewriteRule ^/([-¸·{|}´`'"+*^¯¨¬\\]|''|``|\^\^)(/?([^/]+)(/.+)?/)?$ http://www.domain.com/~$2 [R=permanent,L]
Explanations on those configuration commands:
I don't think, there is lot to explain for the
RedirectMatch
command: Short said it substitutes
the strings "-", "¸", "·", "{",
"|", "}", "´", "`", "'",
""", "+", "*", "^",
"¯", "¨", "¬", "\", "''",
"``" or "^^" if they appear directly after the first
"/" in the URI with "~".
The RewriteRule
does nearly the same, but
has a little bit different syntax and string groups which are tested
by the RewriteCond
commands explained beyond.
The distinction between part a and b is necessary, because if
you have file which has the same name as the user directory (e.g.
/+abc
and /~abc/
) and someone requests the
user directory without the "~" but with the ending
"/" (e.g. /+abc/
, without the distinction the
file would be returned (and $PATH_INFO
would be set to
"/". But what we want is a redirect to the user
directory.
RewriteCond /var/htdocs/$1$2 !-d
tests, if
the requested object isn't a directory. If it is a directory, we won't
do any redirect.
RewriteCond /var/htdocs/$1$2 !-f
tests, if
the requested object isn't a file. If it was, we won't do any
redirect. If the URL ends with "/", we are looking for a
directoy, so it's not necessary to test if it's a file.
RewriteCond /~$3$4 -U
tests, if this URL
with the first character(s) substituted by a "~" leads to
something reasonable (e.g. a file, a directory or even a redirect!).
If it does, we redirect there, if not, we do nothing and the surfer
wil get one of those popular 404s... :-/
Beware: Using subrequest on more frequently used URLs (I don't think the above mentioned charachters appear very often at the beginning of an URL, if at all.), it may slow down your server quite a lot.
Example:
People often forget the "~" in URLs.
This also happened a few times on our server. (Some also did add a "~" to URLs... :-).
Here's a solution, using mod_rewrite without doing too much subrequests for testing:
# Part a: URL does not end with "/" RewriteCond /var/htdocs/$1$2 !-d RewriteCond /var/htdocs/$1$2 !-f RewriteCond /home/$1/public_html$2 -f [OR] RewriteCond /home/$1/public_html$2 -d RewriteRule ^/([^-¸·{|}´`'"+*^¯¨¬\\/~]+)(/.*[^/])?$ http://www.domain.com/~$1$2 [R=permanent,L] # Part b: URL ends with "/" RewriteCond /var/htdocs/$1$2 !-d RewriteCond /home/$1/public_html$2 -f [OR] RewriteCond /home/$1/public_html$2 -d RewriteRule ^/([^-¸·{|}´`'"+*^¯¨¬\\/~]+)(/.+)?/$ http://www.domain.com/~$1$2 [R=permanent,L] # Part c: long Username aliases. RewriteCond $1 ^(olafsdottir|rolshoven)$ RewriteCond /~$1$2 -U RewriteRule ^/([^-¸·{|}´`'"+*^¯¨¬\\/~]+)(/.*)?$ http://www.domain.com/~$1$2 [R=permanent,L]
Explanations on those configuration commands:
The RewriteRule
redirects all URLs, not
starting with "~" (or one of the above mentionend typos), if
an appropriate user exists and he has a public_html
subdirectory in his home directory. This is tested by the RewriteCond
commands explained beyond.
The distinction between part a and b is necessary for the same
reason as above, RewriteCond /var/htdocs/$1$2 !-d
and
RewriteCond /var/htdocs/$1$2 !-f
are working also the
same way as above.
RewriteCond /home/$1/public_html$2 -f [OR] RewriteCond
/home/$1/public_html$2 -d
tests, if this URL with a
"~" added in front leads to a file or directory. If it does,
we redirect there, if not, we do nothing and the surfer wil get one of
those popular 404s... :-/
Beware: Using subrequest in this case
will slow down your server a lot, because nearly every URL is matched
by the RewriteRule
command!
RewriteCond $1 ^(olafsdottir|rolshoven)$
is
necessary for user which have long names and the part behind the
"~" and therefore or for other reasons doesn't match their
user name.
RewriteCond /~$1$2 -U
tests, if this URL
with the first character(s) substituted by a "~" leads to a
file, directory or redirect. If it does, we redirect there, if not, we
do nothing and the surfer will get one of those popular 404s...
:-/
Because of the user names are already give in the above
RewriteCond
command, we can use a suqrequest here to
test, if the URL with a "~" added in front leads to a file or
directory. This is not necessary, because it may point to file that
doesn't exist and IMHO this isn't worth a redirect. And it also looks
like a not-so-well administrated web server if it does redirect which
lead to a 404...
[This bug escapes "?" and "#" when using
RedirectMatch
.]
Since 6-May-2001 there exists a patch against Apache 2.0, which was submitted on 11-May-2001. See #7503.
This patch seems to work for Apache 1.3.x, if you replace any occurence of the string "apr" with "ap" in the patch. But I can't yet say if it's stable, because that modification just was a guess, which at least did not crash. :-)
If your problem are question marks and not hashes, you may pass data instead of via a query string via the path info. Therefore you just have to substitute the question mark in front of the query string with als slash: Use
RedirectMatch ^/test([0-9]+) http://www.dagstuhl.de/test.shtml/$1
instead of
RedirectMatch ^/test([0-9]+) http://www.dagstuhl.de/test.shtml?$1
because the last line doesn't work (yet).
If you use mod_rewrite, you can use a non-parsed-header (nph) cgi-script to do the redirect, because -- as the name says -- the header won't be parsed and therefore nothing will be escaped:
/var/cgi-bin/nph-xredirect.cgi
:
#!/usr/bin/perl $| = 1; print <<EOF; HTTP/1.0 302 Moved Temporarily Server: $ENV{'SERVER_SOFTWARE'} Location: $ENV{'PATH_INFO'} Content-type: text/html <HTML> <HEAD> <TITLE>302 Moved Temporarily (Extended)</TITLE> </HEAD> <BODY> <H1>Moved Temporarily (Extended)</H1> The document has moved <A HREF="$ENV{'PATH_INFO'}">here</A>. </BODY> </HTML> EOF
You call the cgi-script somewhat like that:
RewriteRule ^/A/([0-9]{5})$ /var/cgi-bin/nph-xredirect.cgi/A/#$1 [T=application/x-httpd-cgi,L]
This line redirects e.g. request to "/A/12345"
to "/A/#12345" and not to
"/A/%2312345" as Apache 1.3.x would do if you
use RedirectMatch
for that.
I found this workaround at the Users Guide to URL Rewriting with the Apache Webserver by Ralf S. Engelschall and modified it a little bit for better readability and less redundancy.
mod_macro by Fabien Coelho provides a macro feature for the Apache configuration files without the overhead of e.g. m4 or mod_perl. This also reduces the number of onfiguration typos made during typing repetitive lines or cut and paste.
I use it most time to capsulate often repeated access configurations:
<Macro AllowDagstuhl> Allow from .dagstuhl.de 192.76.146.0/255.255.255.0 localhost 127.0.0.1 AuthType Basic AuthName "IBFI Schloss Dagstuhl: Staff Only" AuthUserFile /www/etc/passwd AuthGroupFile /www/etc/group require group dagstuhl Satisfy any </Macro> <Macro AllowDagstuhlGuests> Allow from .dagstuhl.de 192.76.146.0/255.255.255.0 localhost 127.0.0.1 AuthType Basic AuthName "IBFI Schloss Dagstuhl: Guests Only" AuthUserFile /www/etc/passwd AuthGroupFile /www/etc/group require group guest dagstuhl Satisfy any </Macro> <Macro AllowUniSB> Allow from .uni-sb.de 134.96.0.0/255.255.0.0 </Macro> <Macro AllowMPII> Allow from .mpi-sb.mpg.de 139.19.0.0/255.255.0.0 </Macro> <Macro AllowAllHosts> <Limit GET HEAD POST OPTIONS PROPFIND> Order allow,deny Allow from all </Limit> <LimitExcept GET HEAD POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Macro> <Macro AllowCampus> Use AllowDagstuhlGuests Use AllowUniSB Use AllowMPII </Macro> <Macro NoOtherMethods> # PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK <LimitExcept GET HEAD POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Macro>
So my <Limit>
sections just look like this:
<Location /foobar> <Limit GET HEAD POST OPTIONS PROPFIND> Order deny,allow Use AllowCampus </Limit> Use NoOtherMethods </Location>
And not like this:
<Location /foobar> <Limit GET HEAD POST OPTIONS PROPFIND> Order deny,allow Allow from .uni-sb.de 134.96.0.0/255.255.0.0 Allow from .mpi-sb.mpg.de 139.19.0.0/255.255.0.0 Allow from .dagstuhl.de 192.76.146.0/255.255.255.0 localhost 127.0.0.1 AuthType Basic AuthName "IBFI Schloss Dagstuhl: Guests Only" AuthUserFile /www/etc/passwd AuthGroupFile /www/etc/group require group guest dagstuhl Satisfy any </Limit> # PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK <LimitExcept GET HEAD POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Location>
There are a lot more possibilities to ease configuration with mod_macro and you also can have parameters to macros. See the mod_macro home page for details and download.
Letzte Änderung: URL: http://fsinfo.noone.org:80/~abe/apache-tips/index.html Handcoded and valid HTML 4.01 and CSS 2. |
Copyright © 1999-2024 by
Axel Beckert
<abe at cs.uni-sb.de> Server: Apache/2.4.25 (Debian) on SunOS 4.1.3 @ fsinfo.cs.uni-sb.de (Fachschaftsrat Informatik) Browser: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) @ (none) |