Cómo:
Hay dos formas principales para redireccionar todas las peticiones
de un servidor entero a una dirección única:
una requiere el uso de mod_rewrite y la otra el uso de un
script CGI.
Primero: si todo lo que necestitas hacer es migrar el servidor de
un nombre a otro, simplemente, puedes usar la directiva Redirect,
facilitada por mod_alias:
Redirect /
http://www.apache.org/
Como Redirect remitirá a la ruta completa puede,
sin embargo, no ser apropiado, por ejemplo, cuando la estructura
del directorio ha cambiado después de moverlo y, simplemente,
quieres dirigir a la gente a la página de inicio.
La mejor opción es usar el módulo estándar
de Apache mod_rewrite. Si el módulo está
compilado, las líneas siguientes
RewriteEngine On
RewriteRule / .* http://www.apache.org/ [R]
mandarán un HTTP 302 Redirect contra el cliente y,
sea la que sea lo que dieron en la URL original,
enviarán a "e;http://www.apache.org/"e;.
La segunda opción es instalar
un ScriptAlias señalando a un script CGI que genere
el estado 301 ó 302 y la localización de otro servidor.
Usando un script CGI puedes interceptar varias peticiones y tratarlas
de una forma diferenciada, por ejemplo puedes desear interceptar una petición
POST, de manera que el cliente no se redirija a un script en otro servidor que
espera la información del método POST
(un redireccionamiento perdería esta información del método
POST). Podrías, también, usar un script CGI si no quieres
compilar el módulo mod_rewrite en tu servidor.
Esta es la manera de redirigir todas las peticiones a un script en el archivo de configuración del servidor:
ScriptAlias /
/usr/local/httpd/cgi-bin/redirect_script/
y este es un sencillo script en Perl para redirigir las peticiones:
#!/usr/local/bin/perl
print "Status: 302 Moved Temporarily\r\n" .
Location: http://www.some.where.else.com/\r\n" .
"\r\n";
Tarde o temprano, querrás reiniciar los ficheros de bitácora
(access_log y error_log) porque son demasiado grandes
o porque están llenos de información vieja que ya no es necesaria.
access.log suele crecer 1Mb por cada 10.000 peticiones.
La mayoría de la gente trata primero de reemplazar el fichero moviéndolo o borrándolo. Pero esta no es la forma de trabajo más adecuada.
Apache continuará escribiendo en el fichero de bitácora sobre la misma salida que tenía antes de moverlo. Esto generará un nuevo fichero de bitácora recién creado que será tan grande como el viejo, pero que contendrá miles (o millones) de caracteres nulos.
El procedimiento correcto es mover el fichero de bitácora y, entonces, indicáselo a Apache comunicándole que debe reabrir los ficheros.
Para avisar a Apache se utiliza la señal SIGHUP (-l), por ejemplo:
mv access_log access_log.old
kill -1 `cat httpd.pid`
Nota: httpd.pid es un fichero que contiene los identificadores de los
procesos del demonio http de Apache, y que Apache guarda en el mismo
directorio que los ficheros de bitácora.
Mucha gente utiliza este procedimiento para reemplazar (y realizar las copias de seguridad) de sus ficheros de bitácora todas las noches o semanalmente.
¿Alguna vez te has preguntado por qué algunos
clientes están interesados
en un fichero denominado robots.txt,
que no tienes y nunca tuviste?
Estos clientes se denominan robots (también son conocidos como rastreadores, arañas y oreos bonitos nombres), esto es, clientes automáticos especiales que recorren la red buscando recursos interesantes.
Muchos de estos robots son usados para generar un tipo de índice de la red que sirve de base a los motores de búsqueda para localizar la información.
robots.txt proporciona una manera de limitar las actividades de estos
robots en el sitio web o, más a menudo, dejar el sitio web tranquilo.
Cuando los primeros robots fueron desarrollados, tenían mala reputación puesto que enviaban cientos de peticiones a cada sitio web y a menudo producían sobrecargas. Esto ha mejorado mucho desde entonces, gracias a la Directiva para la programación de Robots, pero, a pesar de ello, algunos robots pueden presentar una conducta antipática que los administradores de sitios web no estén dispuestos a tolerar y deseen parar.
Otra razón es que algunos administradores de sitios web quieren bloquear el acceso de los robots por la manera en que la información dinámica reunida por los robots es posteriormente indexada. Frecuentemente hay sistemas para anotar documentos mal usados puesto que pueden ser indexados por robots nómadas. Por lo tanto, el índice generado a menudo revertirá en un algoritmo poco satisfactorio para determinar qué se ha indexado.
Normalmente, los índices son construidos a partir del texto que aparece en los títulos del documento (dentro de la etiqueta: <TITLE>) o en los encabezamientos (marcados con las etiquetas <H1>) y, muy a menudo, las palabras indexadas son completamente irrelevantes o engañosas sobre el contenido del documento. El peor índice es el que utiliza cada palabra del documento. Inevitablemente, esto provoca que los motores de búsqueda ofrezcan sugerencias de mala calidad que hacen perder un tiempo valioso tanto a los usuarios como a los servidores.
Si decides excluir los robots completamente o limitar
las zonas en las que puedan vagar, se puede incluir un fichero
robots.txt; remitirse a
las páginas de información sobre robots
habilitadas por Martijn Koster para la sintaxis.
La capa de conexión segura SSL (Secure Socket Layer) usa el puerto 443 para las peticiones de páginas seguras. Si tu visualizador permanece justamente allí durante mucho tiempo cuando intentas acceder a una página segura en tu proxy Apache, este puede no estar configurado para manipular SSL. Necesitas dar instrucciones a Apache para que escuche desde el puerto 443 además de los otros puertos en los que habitualmente escucha:
Listen 80
Listen 443
Entonces queda fijado el proxy seguro en tu visualizador desde el puerto 443. Esto debería valer.
Si el proxy está enviando peticiones a otro proxy, puedes tener fijada
la directiva ProxyRemote de otro modo. Aquí está mi
configuración:
ProxyRemote http://nicklas:80/ http://proxy.mayn.franken.de:8080
ProxyRemote http://nicklas:443/ http://proxy.mayn.franken.de:443
Las peticiones sobre el puerto 80 de mi proxy nicklas
son reenviadas a proxy.mayn.franken.de:8080, mientras que
las peticiones sobre el puerto 443 son reenviadas a
proxy.mayn.franken.de:443. Si el proxy remoto no está
configurado para manipular el puerto 443, entonces la última
directiva puede ser omitida. Las peticiones SSL solamente van sobre
el primer proxy.
Advierte que Apache NO tiene que ser configurado para servir páginas seguras con SSL. El Proxy SSL es una cosa diferente que usar esto.
Cómo: