Advertisement
  1. Code
  2. Web Development

Una guía detallada de mod_rewrite para Apache

Scroll to top
Read Time: 27 mins

Spanish (Español) translation by Andrea Jiménez (you can also view the original English article)

Dos veces al mes, revisamos algunas de las publicaciones favoritas de nuestros lectores a lo largo de la historia de Nettuts+. Este tutorial se publicó por primera vez el pasado mes de septiembre.

Cuando la gente piensa en la configuración de .htaccess, lo primero que se les ocurre es la manipulación de URL con mod_rewrite. Pero a menudo se sienten frustrados por la complejidad de mod_rewrite. Este tutorial te guiará a través de todo lo que necesitas saber para las tareas mod_rewrite más comunes.

Discursos Mod_rewrite

Las opiniones sobre mod_rewrite varían bastante. Para tener una idea rápida de lo que piensa el mundo, simplemente realicé una búsqueda en Twitter sobre "mod_rewrite". Esta es una muestra de lo que se devolvió.

mldk: ¡Aargh! .htaccess y mod_rewrite pueden ser un dolor de cabeza en ---!

bsterzenbach: Hombre, me encanta mod_rewrite. Podría trabajar con él el resto de mi vida y aún no dominarlo, es tan poderoso

mikemackay: Aún me encanta la flexibilidad total de mod_rewrite, viniendo al rescate nuevamente. A menudo tan pasado por alto... ¡Y más fácil de lo que piensas!

hostpc: Odio mod_rewrite. No puedo hacer que esta maldita aplicación funcione correctamente :(

awanderingmind: Oh Wordpress y Apache, cómo me molestas. ¡Maldito sea Mod_rewrite!

danielishiding: ¡¿Por qué no funciona mod_rewrite?! ¡Maldita sea!

Algunas cosas que noté son que las personas reconocen claramente el poder de mod_rewrite, pero a menudo se sienten frustradas por la sintaxis. Eso no es sorprendente, considerando que la página principal de la documentación mod_rewrite de Apache dice esencialmente lo mismo:

A pesar de la gran cantidad de ejemplos y documentos, mod_rewrite es vudú. "Maldito vudú genial, pero sigue siendo vudú". -Brian Moore

¡Qué apagón! Entonces, en este artículo, realmente voy a bajar un poco las cosas. No solo abordaremos la sintaxis de mod_rewrite, sino que también proporcionaré un flujo de trabajo que puedes usar para depurar y resolver tus problemas de mod_rewrite. A lo largo del camino, revisaremos algunos ejemplos útiles del mundo real.

Antes de comenzar, una nota de precaución: al igual que con muchos temas, este en particular, ¡no aprenderás a menos que lo intentes por tu cuenta! Esa es una de las razones por las que me enfocaré en enseñar un flujo de trabajo de depuración. Como de costumbre, demostraré cómo configurar tu sistema si aún no tienes el módulo cargado. Te incito a trabajar con los ejemplos en tu propio servidor, preferiblemente, en un entorno de prueba.


¿Qué es mod_rewrite?

mod_rewrite es un módulo de Apache que permite la manipulación del lado del servidor de las URL solicitadas.

mod_rewrite es un módulo de Apache que permite la manipulación del lado del servidor de las URL solicitadas. Las URL entrantes se comparan con una serie de reglas. Las reglas contienen una expresión regular para detectar un patrón en particular. Si el patrón se encuentra en la URL y se cumplen las condiciones adecuadas, el patrón se reemplaza con una cadena o acción de sustitución proporcionada. Este proceso continúa hasta que no quedan más reglas o se le dice explícitamente al proceso que se detenga.

Esto se resume en estos tres puntos:

  • Hay una lista de reglas que se procesan en orden.
  • Si una regla coincide, comprueba las condiciones de esa regla.
  • Si todo va bien, hace una sustitución o acción.

Ventajas de mod_rewrite

Hay algunas ventajas obvias de usar una herramienta de reescritura de URL como esta, pero hay otras que pueden no ser tan obvias.

mod_rewrite se usa más comúnmente para transformar URL feas y crípticas en lo que se conoce como "URL amigables" o "URL limpias".

Como beneficio adicional, estas URL también son más amigables con los motores de búsqueda. Ten en cuenta el siguiente ejemplo:

El enlace final no solo es más agradable a la vista, sino que también es posible que los motores de búsqueda extraigan un significado semántico de él. Este tipo básico de reescritura de URL es una de las formas en que se usa mod_rewrite. Sin embargo, como verás, puede hacer mucho más que estas simples transformaciones.

Ampliando el mismo ejemplo, algunas personas afirman que hay beneficios de seguridad al hacer que mod_rewrite transforme tus URL. Dado el mismo ejemplo, imagina el siguiente ataque a la identificación del usuario:

En el primer ejemplo, el script PHP está siendo invocado explícitamente y debe manejar el número de id no válido. Una secuencia de comandos mal escrita probablemente fallaría y, en un caso más extremo (en una aplicación web mal escrita), una entrada incorrecta podría dañar los datos. Sin embargo, si al usuario solo se le muestran las URL más amigables. nunca sabrían que existía la página user.php.

Intentar el mismo ataque en ese caso probablemente fallaría incluso antes de que llegue al script PHP. Esto se debe a que, en el núcleo de mod_rewrite, se encuentra la coincidencia de patrones de expresión regular. En el caso de ejemplo anterior, habría esperado un número, por ejemplo (\d+), no caracteres como a-z. Esta capa adicional de abstracción es agradable desde una perspectiva de seguridad.


Habilitación de mod_rewrite en el servidor

La habilitación de mod_rewrite o cualquier módulo de apache debe realizarse desde el archivo de configuración global (httpd.conf).

Al igual que habilitar el soporte .htaccess, habilitar mod_rewrite o cualquier módulo de Apache debe realizarse desde el archivo de configuración global (httpd.conf). Al igual que antes, dado que el uso de mod_rewrite está tan extendido, las empresas de hosting casi siempre lo tienen habilitado. Sin embargo, si sospechas que tu empresa de alojamiento no lo hace, y lo probaremos a continuación, comunícate con ellos y es probable que lo habiliten.

Si lanzaste tu propia instalación de Apache, vale la pena señalar que mod_rewrite debe incluirse cuando se compila, ya que no se hace de forma predeterminada. Sin embargo, es tan común que casi todas las guías de instalación, incluidas las de Apache, muestran cómo en su ejemplo.

Si eres el administrador de tu servidor web y quieres asegurarte de cargar el módulo, debes buscar en el archivo httpd.conf. En el archivo de configuración, habrá una gran sección que carga un montón de módulos. La siguiente línea probablemente aparecerá en algún lugar dentro del archivo. Si es así, ¡genial! Si está comentado, lo que significa que hay un símbolo # al principio de la línea, descomenta el comentario eliminando el #:

La versión anterior de Apache 1.3 puede requerir que agregues la siguiente directiva después de la directiva LoadModule.

Sin embargo, esto parece haber desaparecido en Apache 2 y posteriores. Solo se requiere la directiva LoadModule.

Si tuviste que modificar el archivo de configuración en absoluto (no es probable), entonces tendrás que reiniciar el servidor web. Como siempre, debes recordar hacer una copia de seguridad del archivo original en caso de que necesites volver a él más tarde.


Pruebas de mod_rewrite

Puedes probar si mod_rewrite está habilitado o funciona de varias maneras. Uno de los métodos más simples es ver la salida de la función phpinfo de PHP. Crea esta página PHP muy simple, ábrela en tu navegador y busca "mod_rewrite" en la salida.

mod_rewrite debería aparecer en la sección "Módulos cargados" de la página de la siguiente manera:

Good mod_rewrite enabledGood mod_rewrite enabledGood mod_rewrite enabled

Si no estás usando PHP (aunque lo haré durante el resto del tutorial), hay algunas otras formas de verificarlo. Apache viene con una serie de herramientas de línea de comandos a las que puedes hacer referencia. También puedes usar otras herramientas, como apachectl o httpd para probar directamente el módulo. Hay modificadores de línea de comandos que te permiten comprobar todos los módulos cargados en la instalación existente. Puedes ejecutar lo siguiente para obtener una lista de todos los módulos cargados.

Este comando muestra la página de "ayuda" para el comando. Luego ejecuto el comando y busco "reescribir" en los resultados y muestra que había una línea de salida que coincidía.

apache testapache testapache test

Finalmente, si aún no estás seguro de si está habilitado, ¡solo dale una oportunidad! El siguiente archivo .htaccess redirigirá cualquier solicitud en la carpeta dada al archivo good.html. Eso significa que, si mod_rewrite está funcionando, deberías ver good.html.

Good mod_rewrite workedGood mod_rewrite workedGood mod_rewrite worked
Bad mod_rewrite didnt workBad mod_rewrite didnt workBad mod_rewrite didnt work

Dentro de .htaccess

Como siempre, cualquier cosa que puedas poner en un archivo .htaccess también se puede colocar dentro del archivo de configuración global. Con mod_rewrite, hay una pequeña diferencia si pones una regla en uno u otro. Especialmente:

Si estás poniendo [...] reglas en un archivo .htaccess [...] el prefijo de directorio (/) se elimina de la variable REQUEST_URI, ya que se asume automáticamente que todas las solicitudes son relativas al directorio actual. - Documentación de Apache

Esto es algo a tener en cuenta si ves ejemplos en línea o si estás probando un ejemplo tú mismo: ten cuidado con la barra diagonal inicial. Intentaré aclarar esto a continuación cuando trabajemos juntos en algunos ejemplos.


Expresiones regulares

Este tutorial no pretende enseñarte expresiones regulares. Para aquellos de ustedes que están familiarizados con ellos, las expresiones regulares utilizadas en mod_rewrite parecen variar entre las versiones de Apache. En Apache 2.0 son Expresiones regulares compatibles con Perl (PCRE). Esto significa que muchos de los accesos directos a los que estás acostumbrado, como \w que hace referencia a [A-Za-z0-9_], \d que hace referencia a [0-9] y mucho más existen. Sin embargo, mi empresa de alojamiento en particular utiliza Apache 1.3 y las expresiones regulares son más limitadas.

Recursos de RegEx útiles

Si no conoces expresiones regulares, estos son algunos tutoriales útiles que te pondrán al día rápidamente.

Y algunas referencias que todo el mundo debería conocer:

Si aún no te has tomado el tiempo para aprender expresiones regulares, te sugiero que lo hagas. Es una herramienta increíblemente útil. Como suele ser el caso, no son tan complejos como algunos podrían pensar. Seleccioné los enlaces anteriores de mis años de experiencia trabajando con expresiones regulares. Siento que estas guías hacen un muy buen trabajo al transmitir los conceptos básicos.

El conocimiento de las expresiones regulares es una necesidad si quieres utilizar mod_rewrite de forma eficaz.


Obtener una idea.

De acuerdo, has esperado con suficiente paciencia; repasemos un ejemplo rápido. Esto se incluye en los archivos de origen vinculados. Este es el código del archivo .htaccess:

Antes de que pueda explicar cualquiera de los códigos anteriores, debemos revisar rápidamente los otros archivos en el directorio.

El directorio contiene un index.php y un archivo user.php. El index solo tiene algunos enlaces, de varios formatos, a la página del usuario. El código PHP se utiliza puramente con fines de depuración para confirmar que se accedió a la página y lo que contenía el parámetro "id" dado. Este es el contenido de user.php:

Este ejemplo tiene algunas secciones diferentes. En primer lugar, ten en cuenta que la reescritura de URL debe estar habilitada a través de la directiva RewriteEngine. Si tu archivo .htaccess va a usar reglas de reescritura, siempre debes incluir esta línea. De lo contrario, no puedes estar seguro de si está habilitado o no. Como regla general, inclúyelo siempre. La cadena "on" no distingue entre mayúsculas y minúsculas.

El primer RewriteRule es para controlar la página user.php. Como indican los comentarios, estamos reescribiendo la URL amigable en el formato de la URL normal. Para ello, cuando la dirección URL descriptiva entra como entrada, en realidad la estamos transformando en la dirección URL de la cadena de consulta estándar. Descomponiendo obtenemos:

Estos son algunos ejemplos y una explicación para cada uno:

User.php
Entrante Coincide Captura Saliente Resultado
user.php?id=joe No user.php?id=joe Normal
user/joe Sí joe user.php?id=joe Bien
user/joe/ Sí joe user.php?id=joe Bien
user/joe/x No user/joe/x Falla

El primer ejemplo no se ve afectado por RewriteRule y funciona bien. El segundo y tercer ejemplo coinciden con RewriteRule, se reescriben en consecuencia y terminan funcionando bien también. El último ejemplo no coincide con la regla y continúa intacto. El servidor no tiene un directorio user y no intenta encontrarlo. ¡Esto es como se esperaba, porque user/joe/x es una mala URL en primer lugar!

Este ejemplo fue bastante fácil de entender. Sin embargo, dicho eso, hubo muchos detalles minuciosos que pasé por alto. Para ejecutar scripts más complejos, debemos aclarar exactamente lo que está sucediendo arriba. En la siguiente sección, voy a repasar cada paso del ciclo.

NOTA: Si este ejemplo anterior no funcionó para ti, es posible que tus versiones de Apache o mod_rewrite no sean compatibles con PCRE. Intenta cambiar ^user/(\w+)/?$ en ^user/([a-z]+)/?$. Observa que no usé la abreviatura \w. Si esta versión te funciona, entonces tendrás que evitar los accesos directos regex y en su lugar utilizar sus equivalentes más largos (consulta la anterior sección de expresiones regulares).


Flujo de ejecución en detalle

El flujo de ejecución a través de las reglas de reescritura es simple, aunque no exactamente sencillo. Por lo tanto, voy a desglosarlo detalladamente.

Todo comienza cuando el usuario realiza una solicitud a tu servidor. Escriben una URL en la barra de direcciones de su navegador, su navegador traduce eso en una solicitud HTTP para enviar al servidor, Apache recibe esa solicitud y luego la analiza en partes. A continuación se muestra un ejemplo:

Full URL AnalysisFull URL AnalysisFull URL Analysis

Ten en cuenta que cada vez que menciono una de las variables de Apache, uso una sintaxis de aspecto extraño: %{APACHE_VAR}. Solo lo hago porque es similar a la sintaxis que mod_rewrite utiliza para acceder a sus variables. Sin embargo, lo que es importante es el nombre dentro de las llaves.

Entonces, ¿con qué parte mod_rewrite lidiar? Si estás trabajando dentro de un archivo .htaccess, entonces estás trabajando con la parte REMOTE_URI pero sin la barra diagonal inicial. Tomé nota de esto antes; tiende a ser algo que es muy confuso para la mayoría de las personas cuando comienzan. Sin embargo, si estás trabajando desde dentro del archivo de configuración global, debes dejar la barra diagonal inicial.

Para ser lo más específico posible, enterrada en la Documentación de Apache está esta descripción de la "Parte URL" sobre la que actúa mod_rewrite:

El patrón siempre es una expresión regular que coincide con la ruta de acceso url de la solicitud entrante (la parte después del nombre de host, pero antes de cualquier signo de interrogación que indica el principio de una cadena de consulta). Documentación de Apache

Para eliminar cualquier ambigüedad, resaltado en oro en estas dos URL a continuación está la "Parte de URL" que mod_rewrite actúa dentro de un archivo .htaccess:

The Rewrite Portion of the URLThe Rewrite Portion of the URLThe Rewrite Portion of the URL

Para el resto de esta sección, usaré estas dos direcciones URL para describir el flujo de ejecución. También me referiré a la primera url como la URL "verde" y la segunda como la URL "azul". Usaré "Parte de URL" a lo largo de este análisis, es decir, REMOTE_URI sin la barra diagonal inicial.


Dirección URL vs. URI

Para esos lectores pedantes, estas dos cosas a las que llamo URL son en realidad URI. La definición de un Identificador Uniforme de Recursos (IUR) difiere de un Localizador Uniforme de Recursos (URL).

  • URI: un indicador de dónde está un recurso. Esto significa que varios URI pueden apuntar al mismo recurso, pero son direcciones diferentes. Seguir un URI puede requerir varios saltos o redirecciones hasta que llegue al recurso.
  • URL: un término más estricto que identifica la ubicación exacta de un recurso. Esta sutil diferencia se ha desdibujado con el tiempo de tal manera que a nadie le importa la diferencia. Seguiré usando el término URL, porque la gente se siente más cómoda con él.

Ahora, sabemos sobre qué van a actuar las reglas de reescritura. Una vez que Apache haya analizado la solicitud, la traduce al archivo que cree que es necesario y procede a buscar ese archivo. En este punto, atravesará directorios y se encontrará con los archivos .htaccess. Suponiendo que este archivo habilita RewriteEngine, cualquier RewriteRule podría cambiar la dirección URL. Un cambio lo suficientemente drástico (como uno que apunta a Apache a otro directorio en lugar del directorio original al que se dirigía) hará que Apache emita una sub-solicitud y proceda a buscar el nuevo archivo.

En la mayoría de los casos, las sub-solicitudes son invisibles para ti.

En la mayoría de los casos, las sub-solicitudes son invisibles para ti. No es importante conocer este detalle de implementación para la mayoría de las reescrituras simples que alguna vez escribirás o usarás. Lo que es más importante saber es cómo Apache procesa las reglas de reescritura dentro de un archivo .htaccess.

Las reglas de un archivo .htaccess se procesan en el orden en que aparecen. Ten en cuenta que cada RewriteRule está actuando en la "parte de dirección URL" que es similar a la REMOTE_URI. Cuando una regla realiza una sustitución, la "Parte URL" modificada se entregará a la siguiente regla. ¡Esto significa que la URL que está procesando una regla puede haber sido editada por una regla anterior! La dirección URL se actualiza continuamente por cada regla que coincide. ¡Esto es importante recordarlo!

Diagrama de flujo

Este es un diagrama de flujo que intenta proporcionar una visualización del flujo genérico de ejecución a través de múltiples reglas en un archivo .htaccess:

mod_rewrite flow chartmod_rewrite flow chartmod_rewrite flow chart

Ten en cuenta que, en la parte superior del diagrama de flujo, el valor que entra en las reglas de reescritura es esa "Parte URL" y si la sustitución es exitosa, la parte modificada pasa a la siguiente regla.

Cada RewriteCond está asociado a un único RewriteRule.

Me referí a las condiciones de reescritura antes, pero no enté en detalles. Cada RewriteCond está asociado a un único RewriteRule. Las condiciones aparecen antes de la regla que están asociadas entre sí, pero solo se evalúan si el patrón de la regla coincide. Como ilustra el diagrama de flujo, si el patrón de una regla de reescritura coincide, Apache verificará si existe alguna condición para esa regla. Si no los hay, hará la sustitución y continuará. Si hay condiciones, por otro lado, entonces solo hará la sustitución si todas las condiciones son verdaderas. Visualizaremos esto en un ejemplo concreto.

Las direcciones URL con las que estoy trabajando forman parte del "Ejemplo de perfil" que incluí en la descarga del código fuente en el directorio "profile_example". Esto es similar al ejemplo anterior con user.php pero ahora tiene una página profile.php, una regla de reescritura agregada y una condición.

Revisemos el código y el flujo de ejecución de Apache a través de él:

Profile Rewrite RulesProfile Rewrite RulesProfile Rewrite Rules

Aquí, hay dos reglas. La regla #1 es la misma que el ejemplo de usuario que revisamos anteriormente. La #2 es nueva; observa que tiene una condición. La "parte de la URL" que hemos estado discutiendo pasa por las reglas en orden, de arriba a abajo.

La clave para entender este ejemplo es entender primero el objetivo. Voy a permitir URL de perfil amigables, pero en realidad voy a prohibir explícitamente el acceso a la página PHP directamente. Ten en cuenta que algunas personas podrían decir que esto es una mala idea. Podrían decir que, como desarrollador, esto hará que las cosas sean más difíciles de depurar. Eso es ciertamente cierto; En realidad, no recomiendo hacer un truco como este, ¡pero es un excelente ejemplo! Usos más prácticos para mod_rewrite aparecerán más adelante en este tutorial.

Con eso en mente, veamos qué sucede con nuestra URL verde. Queremos que tenga éxito.

Green URL ExecutionGreen URL ExecutionGreen URL Execution

En la parte superior, verás la variable THE_REQUEST de Apache. Pongo esto en la parte superior porque, a diferencia de muchas de las variables de Apache con las que trataremos, durante la duración de la solicitud, ¡este valor de las variables nunca cambiará! Esa es una de las razones por las que el artículo #2 utiliza %{THE_REQUEST}. Debajo de THE_REQUEST, vemos la "Parte de url" verde que entra en la primera regla:

  • La dirección URL coincide con el patrón.
  • No hay condiciones, así que continúa.
  • Se realiza la sustitución.
  • No hay marcas, así que continúa.

Después de pasar por la primera regla, la dirección URL cambió. La URL total fue reescrita a profile.php?id=joe, que Apache luego descompone y actualiza muchas de sus variables. La parte ?id=joe se nos oculta y profile.php, la nueva "Parte URL", continúa en la segunda regla. Este es nuestro primer encuentro con las condiciones:

  • La dirección URL coincide con el patrón.
  • Hay condiciones, así que probaremos las condiciones.
  • THE_REQUEST no contiene profile.php, por lo que se produce un error en la condición.
  • Dado que se produjo un error en una condición, ignoramos la sustitución y las marcas.
  • Esta regla no modifica la dirección URL.

En este punto, completamos todas las reescrituras y la página profile.php?id=joe se recuperará correctamente.


Así es como se ve la ejecución de la URL azul, la que queremos que falle:

Blue URL ExecutionBlue URL ExecutionBlue URL Execution

De nuevo coloqué el valor THE_REQUEST en la parte superior. La "Parte de url" azul entra en la Regla #1:

  • La dirección URL no coincide con el patrón.
  • Todo lo demás se omite y la dirección URL continúa sin cambios.

La primera regla era fácil. Como suele ser el caso, una dirección URL que tengas no coincidirá con el patrón de una regla y continuará intacta. Después, entra en la regla #2:

  • La dirección URL coincide con el patrón.
  • Hay condiciones, así que las probaremos.
  • THE_REQUEST contiene profile.php, por lo que la condición pasa.
  • Podemos hacer la sustitución.
  • ”-” es una sustitución especial que significa: no cambies nada.
  • Hay marcas en la regla, por lo que procesamos las marcas.
  • Hay una marca F, lo que significa devolver una respuesta prohibida.
  • Se le envía una respuesta 403 Forbidden al cliente.

La marca F se refiere a una "respuesta prohibida".

Vale la pena volver a iterar algunas cosas. Para que la sustitución funcione, todas las condiciones tienen que pasar. En este caso, solo hay uno; pasa, por lo que se produce la sustitución. Ten en cuenta que - es una sustitución especial que no cambia nada. Esto es útil cuando quieres utilizar marcas para hacer algo por ti, que es exactamente lo que queremos hacer en este caso.

Este es el desglose familiar de la tabla de direcciones URL de ejemplo y sus respuestas:

Profile.php
Entrante Coincide Captura Saliente Resultado
profile.php?id=joe Sí (#2) profile.php?id=joe Prohibido
profile/joe Sí (#1) joe profile.php?id=joe Bien
profile/joe/ Sí (#1) joe profile.php?id=joe Bien
perfil/joe/x No profile/joe/x Falla

Sintaxis

Antes de repasar la sintaxis de RewriteRule y RewriteCond, te sugiero que primero descargues la hoja de referencia de AddedBytes. Esta hoja de referencia enumera las variables y marcas de servidor más útiles, tiene consejos sobre expresiones regulares e incluso algunos ejemplos.

Comencemos con RewriteRule. Siempre puedes visitar la documentación de Apache en RewriteRule si necesitas más información o instrucciones.

Syntax of RewriteRuleSyntax of RewriteRuleSyntax of RewriteRule

La hoja de referencia, vinculada a arriba, muestra las diversas marcas que están disponibles para ti. Si bien muchos tutoriales hablan de estos en detalle, simplificaremos las cosas y revisaremos los que veo que se usan con más frecuencia en proyectos del mundo real.

Syntax of RewriteCondSyntax of RewriteCondSyntax of RewriteCond

Flujo de trabajo de depuración

Cuando trabajes con mod_rewrite y crees nuevas reglas, siempre comienza con una versión simple y simplificada de la regla y avanza hasta la versión final. Resiste la tentación de hacer todo a la vez. Lo mismo se aplica a las condiciones. Agrega reglas y condiciones de una en una. ¡Prueba con frecuencia!

El concepto clave que estoy tratando de transmitir con este enfoque es que esto te permitirá saber rápidamente si un cambio que realizaste no funciona correctamente o si hace que algo funcione incorrectamente. De lo contrario, inevitablemente te encontrarás con algún tipo de error y tendrás que revertir todos los cambios realizados para rastrear cuál fue el problema. Este es un enfoque muy de montaña rusa y probablemente conducirá a la frustración. Sin embargo, si siempre avanzas de manera constante y cada paso del camino se mueve hacia puntos de control viables, estarás en una forma mucho, mucho mejor.

La gente a menudo ignora este consejo, crea una regla compleja y no funciona. Horas más tarde descubren que el problema no estaba en la parte compleja, sino que fue un simple error en la expresión regular que podría haber sido capturado mucho antes si hubieran construido cuidadosamente la regla como expliqué anteriormente. Lo mismo ocurre con la deconstrucción de una regla para aplicarle ingeniería inversa a un problema. ¡Este enfoque reducirá seriamente la frustración!


En los ejemplos

En los siguientes ejemplos, siempre asumiremos que el dominio del sitio web es example.com. Este nombre de dominio es importante porque afecta a la variable HTTP_HOST, así como especifica una URL de redirección a otro archivo en tu sitio web. Ten esto en cuenta si tienes la intención de modificar cualquiera de los siguientes ejemplos para tu propio sitio web. Si es así, simplemente reemplaza "example.com" con tu dominio. Por ejemplo, Nettuts+ reemplazaría "example.com"; con "nettuts.com".


Eliminación de www

Esta es la regla de reescritura más clásica. El siguiente script escuchará a cualquier persona que llegue a tu sitio web a través de http://www.example.com. Aquellos que lo hagan recibirán una redirección completa y, por lo tanto, la barra de ubicación de su navegador se actualizará en consecuencia.

El RewriteRule anterior coincide con cualquier cosa y lo guarda como $1, según lo especificado por los parientes de ajuste. La parte importante de este ejemplo, sin embargo, es rewriteCond. Esta condición comprueba la variable HTTP_HOST para determinar si comenzó con "www.". Si esta condición es true, se produce la reescritura:

  • La sustitución es una URL completa (comienza con http://)
  • La sustitución contiene $1, que se capturó anteriormente
  • La marca [R=301] redirige el explorador a la dirección URL reescrita. Esta es una redirección difícil en el sentido de que obliga al navegador a cargar la nueva página y actualizar su barra de ubicación con la nueva URL.
  • La marca [L] indica que esta es la última regla que se va a analizar. Más allá de esta línea, el motor de reescritura debe detenerse.

Si la URL entrante hubiera sido "http://www.example.com/user/index.html", entonces HTTP_HOST se habría configurado en www.example.com y la reescritura se activaría, creando http://example.com/user/index.html.

Por otro lado, si la URL entrante hubiera sido "http://example.com/user/index.html", entonces HTTP_HOST habría sido example.com, la condición fallaría y el motor de reescritura continuaría con la URL sin cambios.


Prohibir hotlinking

Hotlinking, conocido como Inline Linking en Wikipedia, es el término utilizado para describir un sitio que se desprende de otro sitio.

Hotlinking, conocido como Inline Linking en Wikipedia, es el término utilizado para describir un sitio que se desprende de otro sitio. Por lo general, un sitio, Leecher, incluirá un enlace a algún archivo multimedia (digamos una imagen o video) que está alojado en otro sitio, Content Host. En este escenario, los servidores del Host de contenido están desperdiciando ancho de banda sirviendo contenido a algún otro sitio web.

El enfoque más común y básico para prevenir los enlaces directos es incluir en la lista blanca un número específico de sitios web y bloquear todo lo demás. Para determinar quién solicita el contenido de tu sitio, puedes consultar el remitente.

El encabezado HTTP_REFERER lo configura el navegador o el cliente que solicita el recurso.

En última instancia, no es 100% confiable, sin embargo, generalmente es más que efectivo para cesar la mayoría de los hotlinking. Por lo tanto, en nuestro script, necesitamos verificar si el remitente está incluido en una lista de referencias aceptables. Si no, entonces deberíamos recibir una advertencia prohibida:

Anteriormente, RewriteRule comprueba la solicitud de un archivo con cualquier extensión de imagen popular, como .gif, .png o .jpg. Siéntete libre de agregar otras extensiones a esta lista si quieres proteger .flv, .swf u otros archivos.

Los dominios que pueden acceder a este contenido son "example.net" y "example.com". En cualquiera de estos dos casos, se producirá un error en las condiciones de reescritura y no se producirá la sustitución. Sin embargo, si cualquier otro dominio lo intenta, digamos "sample.com", todas las condiciones de reescritura pasarán, se producirá la sustitución y se activará la acción prohibida [F].


Dar a Hotlinkers una imagen de advertencia

En el ejemplo anterior se devuelve una advertencia 404 Forbidden cuando alguien intenta vincular contenido desde tu servidor. De hecho, puedes ir un paso más allá y ¡enviar al hotlinker cualquier recurso de tu elección! Por ejemplo, puedes devolver una imagen de advertencia con texto que diga "no se permite el hotlinking". De esta manera, el abusador se dará cuenta de su error y guardará una copia en su propio servidor. El único cambio requerido es continuar con la sustitución de reescritura y proporcionar la imagen elegida en lugar de la solicitada:

Ten en cuenta que este es un ejemplo de lo que yo llamo un redireccionamiento "duro" o "externo". RewriteRule tiene una dirección URL en la parte de sustitución y también tiene el indicador [R].


Personalizado 404

Un buen truco que puedes hacer con htaccess es determinar si la "Parte URL" actual conduce a un archivo o directorio real en el servidor web. Esta es una manera excelente de crear una página 404 personalizada "Archivo no encontrado". Por ejemplo, si un usuario intenta buscar una página en un directorio particular que no existe, puedes redirigirlo a cualquier página que quieras, como la página index o una página 404 personalizada.

Este es un gran ejemplo de los operadores de prueba de archivos de mod_rewrite. Son idénticos a las pruebas de archivos en scripts de shell bash e incluso scripts de Perl. Anteriormente, la condición comprueba si el REQUEST_FILENAME no es un archivo ni un directorio. En el caso de que no sea ninguno de los dos, no existe tal archivo para la solicitud.

Si no se puede encontrar el nombre de archivo de la solicitud entrante, esta secuencia de comandos carga una página "custom404.html". Ten en cuenta que no hay una marca [R]: se trata de una redirección silenciosa, no una redirección forzada. La barra de ubicación del usuario no cambiará, pero el contenido de la página será "custom404.html".


La seguridad es lo primero

Si tienes varios fragmentos de código de mod_rewrite que quieras distribuir fácilmente a otros servidores o entornos, es posible que quieras tener cuidado. Cualquier directiva no válida en un archivo .htaccess probablemente desencadenará un error interno del servidor. Por lo tanto, si un entorno al que mueves el fragmento no es compatible con mod_rewrite, podrías romperlo temporalmente.

Una solución a este problema es la "comprobación" del módulo mod_rewrite. Esto es posible con cualquier módulo; simplemente envuelve tu código mod_rewrite en un bloque <IfModule>  y estará todo listo:


Conclusión

Espero que este tutorial haya demostrado que mod_rewrite no es tan aterrador. De hecho, sus peculiaridades y obstáculos pueden evitarse con prácticas de desarrollo cuidadosas. ¡Hazme saber si tienes alguna pregunta!

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.