Apache HTTP Server Version 1.3
Is this the version you want? For more recent
versions, check our documentation
index.
Apache HOWTO documentation
How to:
There are two chief ways to redirect all requests for an
entire server to a single location: one which requires the use
of mod_rewrite , and another which uses a CGI
script.
First: if all you need to do is migrate a server from one
name to another, simply use the Redirect
directive, as supplied by mod_alias :
Redirect / http://www.apache.org/
Since Redirect will forward along the complete
path, however, it may not be appropriate - for example, when
the directory structure has changed after the move, and you
simply want to direct people to the home page.
The best option is to use the standard Apache module
mod_rewrite . If that module is compiled in, the
following lines
RewriteEngine On
RewriteRule /.* http://www.apache.org/ [R]
will send an HTTP 302 Redirect back to the client, and no
matter what they gave in the original URL, they'll be sent to
"http://www.apache.org/".
The second option is to set up a ScriptAlias
pointing to a CGI script which outputs a 301
or 302 status and the location of the other server.
By using a CGI script you can intercept
various requests and treat them specially, e.g., you
might want to intercept POST requests, so that
the client isn't redirected to a script on the other server
which expects POST information (a redirect will lose the POST
information.) You might also want to use a CGI script if you
don't want to compile mod_rewrite into your server.
Here's how to redirect all requests to a script... In the
server configuration file,
ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script/
and here's a simple perl script to redirect requests:
#!/usr/local/bin/perl
print "Status: 302 Moved Temporarily\r\n" .
"Location: http://www.some.where.else.com/\r\n" .
"\r\n";
Sooner or later, you'll want to reset your log files
(access_log and error_log) because they are too big, or full of
old information you don't need.
access.log typically grows by 1Mb for each
10,000 requests.
Most people's first attempt at replacing the logfile is to
just move the logfile or remove the logfile. This doesn't
work.
Apache will continue writing to the logfile at the same
offset as before the logfile moved. This results in a new
logfile being created which is just as big as the old one, but
it now contains thousands (or millions) of null characters.
The correct procedure is to move the logfile, then signal
Apache to tell it to reopen the logfiles.
Apache is signaled using the SIGHUP (-1)
signal. e.g.
mv access_log access_log.old
kill -1 `cat httpd.pid`
Note: httpd.pid is a file containing the
process id of the Apache
httpd daemon, Apache saves this in the same directory as the
log files.
Many people use this method to replace (and backup) their
logfiles on a nightly or weekly basis.
Ever wondered why so many clients are interested in a file
called robots.txt which you don't have, and never
did have?
These clients are called robots (also known
as crawlers, spiders and other cute names) - special automated
clients which wander around the web looking for interesting
resources.
Most robots are used to generate some kind of web
index which is then used by a search engine to
help locate information.
robots.txt provides a means to request that
robots limit their activities at the site, or more often than
not, to leave the site alone.
When the first robots were developed, they had a bad
reputation for sending hundreds/thousands of requests to each
site, often resulting in the site being overloaded. Things have
improved dramatically since then, thanks to
Guidelines for Robot Writers, but even so, some robots may
exhibit unfriendly behavior which the webmaster isn't willing
to tolerate, and will want to stop.
Another reason some webmasters want to block access to
robots, is to stop them indexing dynamic information. Many
search engines will use the data collected from your pages for
months to come - not much use if you're serving stock quotes,
news, weather reports or anything else that will be stale by
the time people find it in a search engine.
If you decide to exclude robots completely, or just limit
the areas in which they can roam, create a
robots.txt file; refer to the
robot information pages provided by Martijn Koster for the
syntax.
SSL uses port 443 for requests for secure pages. If your
browser just sits there for a long time when you attempt to
access a secure page over your Apache proxy, then the proxy may
not be configured to handle SSL. You need to instruct Apache to
listen on port 443 in addition to any of the ports on which it
is already listening:
Listen 80
Listen 443
Then set the security proxy in your browser to 443. That
might be it!
If your proxy is sending requests to another proxy, then you
may have to set the directive ProxyRemote differently. Here are
my settings:
ProxyRemote http://nicklas:80/ http://proxy.mayn.franken.de:8080
ProxyRemote http://nicklas:443/ http://proxy.mayn.franken.de:443
Requests on port 80 of my proxy nicklas are
forwarded to proxy.mayn.franken.de:8080, while
requests on port 443 are forwarded to
proxy.mayn.franken.de:443. If the remote proxy is
not set up to handle port 443, then the last directive can be
left out. SSL requests will only go over the first proxy.
Note that your Apache does NOT have to be set up to serve
secure pages with SSL. Proxying SSL is a different thing from
using it.
Apache HTTP Server Version 1.3
|