Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The following page has been changed by VinkoVrsalovic: http://wiki.apache.org/httpd/UrlMapping The comment on the change is: Translation of urlmapping.xml to spanish, for review New page: = 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. * Módulos y directivas relacionados * !DocumentRoot * Ficheros fuera del !DocumentRoot * Directorios de usuario * Redirección de URLs * Proxy Inverso * Motor de reescritura de URLs * Fichero no encontrado === Módulos y directivas 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 omisión 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 aún más poder es requerido, 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án peticiones para las que no se encontrará ningún fichero el en 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.
