THIS IS AN UNOFFICIAL TRANSLATION OF AN OFFICIAL DOCUMENT, IT'S CURRENTLY OPEN FOR REVIEW

ESTA ES UNA TRADUCCIÓN NO OFICIAL DE UN DOCUMENTO OFICIAL, ES SOLAMENTE PARA REVISIÓN

Mapear URLs a ubicaciones de un sistema de ficheros

Este documento explica cómo usa Apache la URL de una petición para determinar la ubicación desde la cual servir un fichero en el sistema de ficheros.

  • Directivas y módulos relacionados
  • DocumentRoot
  • Ficheros fuera del DocumentRoot
  • Directorios de usuario
  • Redirección de URLs
  • Proxy Inverso
  • Motor de reescritura de URLs
  • Fichero no encontrado

Directivas y módulos relacionados

Módulos Relacionados

  • mod_alias
  • mod_proxy
  • mod_rewrite
  • mod_userdir
  • mod_speling
  • mod_vhost_alias

Directivas Relacionadas

  • Alias
  • AliasMatch
  • CheckSpelling
  • DocumentRoot
  • ErrorDocument
  • Options
  • ProxyPass
  • ProxyPassReverse
  • ProxyPassReverseCookieDomain
  • ProxyPassReverseCookiePath
  • Redirect
  • RedirectMatch
  • RewriteCond
  • RewriteMatch
  • ScriptAlias
  • ScriptAliasMatch
  • UserDir

DocumentRoot

El comportamiento por defecto de Apache al decidir qué fichero servir frente a una determinada petición, es agregar la parte de la URL que sigue al nombre de host y puerto (URL-path) de la petición al final de lo especificado en la directiva DocumentRoot de los ficheros de configuración. De esta manera, los ficheros y directorios por debajo del directorio especificado en DocumentRoot forman el árbol básico de documentos que será visible desde la web.

Por ejemplo, si DocumentRoot estuviera configurado como /var/www/html, entonces una petición a la URL http://www.example.com/peces/guppies.html haría que Apache sirviera el fichero /var/www/html/peces/guppies.html al cliente que realizó la petición.

Apache también puede recibir peticiones para más de un host a través de Hosts Virtuales. En este caso, se puede especificar un DocumentRoot diferente para cada host virtual, o se pueden utilizar las directivas provistas por el módulo mod_vhost_alias para determinar dinámicamente el lugar apropiado desde el cual servir el contenido, basándose en la IP o el nombre del host solicitado.

La directiva DocumentRoot se debe especificar en el fichero principal de configuración (httpd.conf) y, de ser pertinente, una vez por cada Host Virtual que se configure.

Ficheros fuera del DocumentRoot

Comúnmente hay circunstancias donde es necesario permitir acceso a través de la web a partes del sistema de ficheros que no están directamente bajo DocumentRoot. Apache ofrece un conjunto de alternativas para conseguir esto. En sistemas Unix, los enlaces simbólicos pueden poner fácilmente partes del sistema de ficheros bajo el directorio especificado en la directiva DocumentRoot. Por razones de seguridad, Apache sólo seguirá enlaces simbólicos si la directiva Options para el directorio en cuestión incluye FollowSymLinks o SymLinksIfOwnerMatch.

Por otra parte, la directiva Alias hará un mapeo de cualquier parte del sistema de ficheros a la web. Por ejemplo, con

Alias /docs /var/web

la URL http://www.example.com/docs/dir/fichero.html será servida desde /var/web/dir/fichero.html. La directiva ScriptAlias funciona de la misma forma, con el efecto adicional de que todo el contenido ubicado en el directorio especificado se tratará como scripts CGI.

Si es necesaria mayor flexibilidad, se pueden usar las directivas AliasMatch y ScriptAliasMatch para hacer sustituciones o encontrar coincidencias utilizando expresiones regulares. Por ejemplo,

ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) /home/$1/cgi-bin/$2

hará un mapeo de la petición a http://example.com/~user/cgi-bin/script.cgi al directorio /home/user/cgi-bin/script.cgi y tratará el fichero resultante como un script CGI.

Directorios de usuario

Tracidionalmente en sistemas Unix al directorio de un usuario en particular puede llamársele ~user/. El módulo mod_userdir extiende esta idea a la web permitiendo que ficheros bajo cada directorio de usuario sea accedido usando URLs como la siguiente.

http://www.example.com/~usuario/fichero.html

Por razones de seguridad, es inapropiado dar acceso directo desde la web al directorio de un usuario. Por lo tanto, la directiva UserDir especifica un directorio ubicado bajo el directorio del usuario donde se !encontrarán los ficheros a ser servidos a través de la web. Usando la opción por omisión, UserDir public_html, la URL de más arriba es mapeada a un directorio como /home/usuario/public_html/fichero.html donde /home/usuario/es el directorio del usuario tal como sale en el fichero /etc/passwd.

Existen formas alternativas a la ya mencionada de la directiva UserDir que pueden utilizarse en sistemas donde /etc/passwd no contiene la ubicación del directorio de usuario.

Hay gente que encuentra el símbolo "~" (cuya representación en HTML es %7e) desagradable y prefieren usar otro conjunto de caracteres para representar los directorios de usuario. Esta funcionalidad no es soportada por mod_userdir. Sin embargo, si los directorios de usuario están estructurados de manera regular, entonces es posible usar la directiva AliasMatch para obtener el efecto deseado. Por ejemplo, para que http://www.example.com/upages/usuario/fichero.html corresponda a /home/usuario/public_html/fichero.html, se debe usar la siguiente directiva AliasMatch:

AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*) /home/$1/public_html/$2

Redirección de URLs

Las directivas de configuración mencionadas en las secciones anteriores le indican a Apache que debe obtener los contenidos desde un lugar específico en el sistema de ficheros y devolverlo al cliente. A veces, es deseable informar al cliente que el contenido solicitado está ubicado en una URL diferente, para que éste haga una nueva petición con la URL definitiva.

A esto se le llama redirección y es implementado por la directiva Redirect. Por ejemplo, si los contenidos del directorio /foo/ bajo el DocumentRoot son movidos al nuevo directorio /bar/, se les puede decir a los clientes que soliciten el contenido desde la nueva ubicación de la siguiente manera:

Redirect permanent /foo/ http://www.example.com/bar/

Esto redireccionará cualquier path en la URL que comience con /foo/ al mismo path en el servidor www.example.com con /bar/ siendo reemplazado por /foo/. Se pueden redireccionar peticiones a cualquier servidor, no solamente al servidor de origen.

Apache provee también la directiva RedirectMatch para redirecciones más complejas. Por ejemplo, para redireccionar peticiones a la página de inicio de un sitio a un lugar diferente pero sin afectar todas las demás peticiones, se puede usar la siguiente configuración:

RedirectMatch permanent ^/$ http://www.example.com/paginainicio.html

Para redireccionar temporalmente todas las páginas de un sitio a una página específica de otro se usa:

RedirectMatch temp .* http://othersite.example.com/paginainicio.html

Proxy Inverso

Apache permite también poner documentos remotos en el espacio de URLs del servidor local. Esta técnica es conocida como proxy inverso (reverse proxy en inglés) porque el servidor web actúa como un servidor proxy al recoger los documentos desde un servidor remoto y devolverlos al cliente. Es distinto a un proxy normal porque al cliente le parece como si los documentos se originaran en el servidor proxy inverso.

En el siguiente ejemplo, cuando los clientes solicitan documentos bajo el directorio /foo/, el servidor obtiene esos documentos desde el directorio /bar/ en el servidor interno.example.com y los devuelve al cliente como si fueran locales.

ProxyPass /foo/ http://interno.example.com/bar/
ProxyPassReverse /foo/ http://interno.example.com/bar/
ProxyPassReverseCookieDomain interno.example.com publico.example.com
ProxyPassReverseCookiePath /foo/ /bar/

La directiva ProxyPass configura al servidor para obtener los documentos adecuados, mientras la directiva ProxyPassReverse modifica las redirecciones que se originen en interno.example.com de manera que apunten al directorio apropiado en el servidor local. De la misma forma, las directivas ProxyPassReverseCookieDomain y ProxyPassReverseCookieDomain reescriben las cookies entregadas por el servidor remoto.

Es importante destacar que los enlaces en los documentos no serán reescritos. Cualquier enlace absoluto en interno.example.com resultará en que el cliente hará la petición directamente hacia interno.example.com, saltándose el proxy. Existe un módulo externo que permite reescribir los links en HTML y XHTML, mod_proxy_html.

Motor de reescritura de URLs

Cuando es necesario realizar sustituciones más complejas, el motor de reescritura de URLs provisto por mod_rewrite puede ser útil. Las directivas provistas por este módulo pueden usar características de la petición como el tipo de navegador o la dirección IP de origen para decidir de donde a donde servir el contenido. Además, mod_rewrite puede usar ficheros de bases de datos externos o programas para determinar qué hacer con una petición. El motor de reescritura es capaz de realizar los tres tipos de mapeos ya mencionados: redirecciones internas (aliases), redirecciones externas y proxy. Se pueden encontrar muchos ejemplos prácticos sobre mod_rewrite en la Guía de reescritura de URLs.

Fichero no encontrado

Siempre habrá peticiones para las que no se encontrará ningún fichero en el sistema de ficheros. Esto puede ocurrir por diversas razones. En algunos casos, puede ser que los documentos hayan sido movidos de un lugar a otro. En este caso, lo mejor es usar Redirección de URLs para informarle a los clientes de la nueva ubicación de los recursos. De esta forma, se puede garantizar que los favoritos y enlaces continuarán funcionando, aun cuando el recurso se encuentra en otra ubicación.

Otra causa frecuente de este tipo de error es el error en la escritura de URLs, ya sea directamente en el navegador, o en enlaces HTML. Apache provee el módulo mod_speling (sic) para ayudar a solucionar este problema. Cuando este módulo está activo, interceptará los errores "Fichero no encontrado" y buscará algún recurso con un nombre similar. Si alguno es encontrado, mod_speling enviará una redirección HTTP al cliente informándole de la ubicación correcta. Si hay múltiples recursos con un nombre similar, se le enviará al cliente una lista con las alternativas disponibles.

  • No labels