Muchos carteles tienen problemas para depurar sus declaraciones RewriteRule y RewriteCond dentro de sus .htaccessarchivos. La mayoría de estos están utilizando un servicio de alojamiento compartido y, por lo tanto, no tienen acceso a la configuración del servidor raíz. No pueden evitar el uso de .htaccessarchivos para reescribir y no pueden habilitar un RewriteLogLevel ", como sugieren muchos encuestados. Además, hay muchas .htaccessdificultades y restricciones específicas que no se cubren bien. Configurar una pila LAMP de prueba local implica demasiada curva de aprendizaje para la mayoría .

Así que mi Q aquí es cómo se lo recomendamos que depurar sus reglas propias . Proporciono algunas sugerencias a continuación. Se agradecerán otras sugerencias.

1. Comprenda que el motor mod_rewrite recorre los .htaccessarchivos . El motor ejecuta este bucle:

   do
     execute server and vhost rewrites (in the Apache Virtual Host Config)
     find the lowest "Per Dir" .htaccess file on the file path with rewrites enabled
     if found(.htaccess)
        execute .htaccess rewrites (in the user's directory)
   while rewrite occurred
   

   Por lo tanto, sus reglas se ejecutarán repetidamente y si cambia la ruta de URI, puede terminar ejecutando otros .htaccessarchivos si existen. Por lo tanto, asegúrese de terminar este ciclo, si es necesario agregando más RewriteCondpara detener el disparo de las reglas. Elimine también cualquier .htaccessconjunto de reglas de reescritura de nivel inferior a menos que tenga la intención explícita de utilizar conjuntos de reglas de varios niveles.

2. Asegúrese de que la sintaxis de cada Regexp sea correcta probando contra un conjunto de patrones de prueba para asegurarse de que sea una sintaxis válida y haga lo que pretende con un rango completo de URI de prueba. Vea la respuesta a continuación para más detalles.

3. Desarrolle sus reglas de forma incremental en un directorio de prueba. Puede utilizar la función "Ejecutar el .htaccessarchivo más profundo en la ruta" para configurar un directorio de prueba (árbol) y conjuntos de reglas de depuración separados aquí sin arruinar sus reglas principales y dejar de funcionar su sitio. Debe agregarlos uno a la vez porque esta es la única forma de localizar fallas en las reglas individuales.

4. Use un código auxiliar de script ficticio para volcar las variables de entorno y servidor . (Consulte el Listado 2 ) Si su aplicación usa, por ejemplo, blog/index.phppuede copiar esto test/blog/index.phpy usarlo para probar las reglas de su blog en el testsubdirectorio. También puede usar variables de entorno para asegurarse de que el motor de reescritura interprete las cadenas de sustitución correctamente, p. Ej.

   RewriteRule ^(.*) - [E=TEST0:%{DOCUMENT_ROOT}/blog/html_cache/$1.html]
   

   y busque estas variables REDIRECT_ * en el volcado phpinfo. Por cierto, usé este y descubrí en mi sitio que tenía que usar %{ENV:DOCUMENT_ROOT_REAL}en su lugar. En el caso del redireccionamiento en bucle, las variables REDIRECT_REDIRECT_ * enumeran el pase anterior. Etc ..

5. Asegúrese de que su navegador no lo muerda al almacenar en caché redirecciones 301 incorrectas . Ver la respuesta a continuación . Mi agradecimiento a Ulrich Palha por esto.

6. El motor de reescritura parece sensible a las reglas en cascada dentro de un .htaccesscontexto, (ahí es donde se RewriteRuleproduce una sustitución y esto recae en otras reglas), ya que encontré errores con solicitudes secundarias internas (1) y un procesamiento incorrecto de PATH_INFO que a menudo puede se evita mediante el uso de los indicadores [NS], [L] y [PT].

¿Algún comentario o sugerencia más?

Listado 1 - phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

Aquí hay algunos consejos adicionales sobre las reglas de prueba que pueden facilitar la depuración de los usuarios en hosting compartido

1. Use un agente de usuario falso

Al probar una nueva regla, agregue una condición para ejecutarla solo con un fakeagente de usuario que usará para sus solicitudes. De esta manera, no afectará a nadie más en su sitio.

p.ej

#protect with a fake user agent
RewriteCond %{HTTP_USER_AGENT}  ^my-fake-user-agent$
#Here is the actual rule I am testing
RewriteCond %{HTTP_HOST} !^www\.domain\.com$ [NC] 
RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L,R=302] 

Si está usando Firefox, puede usar el User Agent Switcher para crear la cadena de agente de usuario falsa y probar.

2. No use 301 hasta que haya terminado las pruebas

He visto muchas publicaciones en las que la gente todavía está probando sus reglas y están usando 301. No lo hagas .

Si no está utilizando la sugerencia 1 en su sitio, no solo usted, sino cualquier persona que visite su sitio en ese momento se verá afectada por el 301.

Recuerde que son permanentes y su navegador los almacena en caché de forma agresiva. Use un 302 en su lugar hasta que esté seguro, luego cámbielo a 301.

3. Recuerde que los 301 se almacenan en caché agresivamente en su navegador

Si su regla no funciona y le parece correcta, y no estaba utilizando las sugerencias 1 y 2, vuelva a realizar la prueba después de borrar la memoria caché del navegador o mientras está en navegación privada.

4. Use una herramienta de captura HTTP

Use una herramienta de captura HTTP como Fiddler para ver el tráfico HTTP real entre su navegador y el servidor.

Mientras que otros podrían decir que usted site does not look right, en cambio, podría verlo e informarlo all of the images, css and js are returning 404 errors, reduciendo rápidamente el problema.

Mientras que otros informarán que usted started at URL A and ended at URL C, podrá ver que comenzaron enURL A, were 302 redirected to URL B and 301 redirected to URL C . Incluso si la URL C era el objetivo final, sabrá que esto es malo para el SEO y necesita ser reparado.

Podrá ver los encabezados de caché que se configuraron en el lado del servidor, reproducir solicitudes, modificar encabezados de solicitud para probar ...

Prueba de reescritura en línea .htaccess

Encontré esta ayuda de Google para RegEx, me ahorró mucho tiempo al tener que cargar nuevos .htaccessarchivos cada vez que hago una pequeña modificación.

desde el sitio:

probador de acceso

Para probar sus reglas de reescritura de htaccess, simplemente complete la url a la que está aplicando las reglas, coloque el contenido de su htaccess en el área de entrada más grande y presione el botón "Verificar ahora".

No olvide que en los archivos .htaccess es una URL relativa que coincide.

En un archivo .htaccess, la siguiente RewriteRule nunca coincidirá:

RewriteRule ^/(.*)     /something/$s

Asegúrese de que la sintaxis de cada Regexp sea correcta

probando contra un conjunto de patrones de prueba para asegurarse de que sea una sintaxis válida y que haga lo que pretende con un rango completo de URI de prueba.

Consulte regexpCheck.php a continuación para obtener un script simple que puede agregar a un directorio privado / test en su sitio para ayudarlo a hacer esto. He mantenido esto breve en lugar de bonito. Simplemente pasa esto a un archivo regexpCheck.phpen un directorio de prueba para usarlo en tu sitio web. Esto lo ayudará a construir cualquier expresión regular y probarla contra una lista de casos de prueba mientras lo hace. Estoy usando el motor PHP PCRE aquí, pero después de haber examinado la fuente de Apache, esto es básicamente idéntico al que se usa en Apache. Hay muchos HowTos y tutoriales que proporcionan plantillas y pueden ayudarlo a desarrollar sus habilidades de expresión regular.

Listado 1 - regexpCheck.php

<html><head><title>Regexp checker</title></head><body>
<?php 
    $a_pattern= isset($_POST['pattern']) ? $_POST['pattern'] : "";
    $a_ntests = isset($_POST['ntests']) ? $_POST['ntests'] : 1;
    $a_test   = isset($_POST['test']) ? $_POST['test'] : array();
    
    $res = array(); $maxM=-1; 
    foreach($a_test as $t ){
        $rtn = @preg_match('#'.$a_pattern.'#',$t,$m);
        if($rtn == 1){
            $maxM=max($maxM,count($m));
            $res[]=array_merge( array('matched'),  $m );
        } else {
            $res[]=array(($rtn === FALSE ? 'invalid' : 'non-matched'));
        }
    } 
?> <p>&nbsp; </p>
<form method="post" action="<?php echo $_SERVER['SCRIPT_NAME'];?>">
    <label for="pl">Regexp Pattern: </label>
    <input id="p" name="pattern" size="50" value="<?php echo htmlentities($a_pattern,ENT_QUOTES,"UTF-8");;?>" />
    <label for="n">&nbsp; &nbsp; Number of test vectors: </label>
    <input id="n" name="ntests"  size="3" value="<?php echo $a_ntests;?>"/>
    <input type="submit" name="go" value="OK"/><hr/><p>&nbsp;</p>
    <table><thead><tr><td><b>Test Vector</b></td><td>&nbsp; &nbsp; <b>Result</b></td>
<?php 
    for ( $i=0; $i<$maxM; $i++ ) echo "<td>&nbsp; &nbsp; <b>\$$i</b></td>";
    echo "</tr><tbody>\n";
    for( $i=0; $i<$a_ntests; $i++ ){
        echo '<tr><td>&nbsp;<input name="test[]" value="', 
            htmlentities($a_test[$i], ENT_QUOTES,"UTF-8"),'" /></td>';
        foreach ($res[$i] as $v) { echo '<td>&nbsp; &nbsp; ',htmlentities($v, ENT_QUOTES,"UTF-8"),'&nbsp; &nbsp; </td>';}
        echo "</tr>\n";
    }
?> </table></form></body></html>

Asegúrese de usar el signo de porcentaje frente a las variables, no el signo de dólar.

Es %{HTTP_HOST}, no ${HTTP_HOST} . No habrá nada en el error_log, no habrá errores internos del servidor, su expresión regular sigue siendo correcta, la regla simplemente no coincidirá. Esto es realmente horrible si trabajas mucho con plantillas django / genshi y tienes ${}una sustitución variable en la memoria muscular.

Uno de un par de horas que perdí:

Si ha aplicado todos estos consejos y solo está recibiendo 500 errores porque no tiene acceso al registro de errores del servidor, tal vez el problema no esté en .htaccess sino en los archivos a los que redirige.

Después de arreglar mi problema .htaccess, pasé dos horas más tratando de solucionarlo un poco más, a pesar de que simplemente me había olvidado de algunos permisos.

Establezca variables de entorno y use encabezados para recibirlas:

Puede crear nuevas variables de entorno con líneas RewriteRule, como lo menciona OP:

RewriteRule ^(.*) - [E=TEST0:%{DOCUMENT_ROOT}/blog/html_cache/$1.html]

Pero si no puede hacer que funcione un script del lado del servidor, ¿cómo puede leer esta variable de entorno? Una solución es establecer un encabezado:

Header set TEST_FOOBAR "%{REDIRECT_TEST0}e"

El valor acepta especificadores de formato , incluido el %{NAME}eespecificador para variables de entorno (no olvide la letra minúscula e). A veces, necesitará agregar el REDIRECT_prefijo, pero no he resuelto cuándo se agrega el prefijo y cuándo no.

Si está creando redirecciones, pruebe con curl para evitar problemas de almacenamiento en caché del navegador. Use -I para buscar solo encabezados http. Use -L para seguir todas las redirecciones.

Encontré esta pregunta al intentar depurar mis problemas de mod_rewrite, y definitivamente tiene algunos consejos útiles. Pero al final lo más importante es asegurarse de tener la sintaxis de expresiones regulares correcta. Debido a problemas con mi propia sintaxis RE, instalar el script regexpCheck.php no era una opción viable.

Pero como Apache utiliza expresiones regulares compatibles con Perl (PCRE), cualquier herramienta que ayude a escribir PCRE debería ayudar. He usado la herramienta RegexPlanet con Java y Javascript RE en el pasado, y me alegró descubrir que también son compatibles con Perl.

Simplemente escriba su expresión regular y una o más URL de ejemplo, y le dirá si la expresión regular coincide (un "1" en la columna "~ =") y, si corresponde, cualquier grupo coincidente (los números en la "división" la columna corresponderá a los números que Apache espera, por ejemplo, $ 1, $ 2, etc.) para cada URL. Afirman que el soporte PCRE está "en beta", pero era justo lo que necesitaba para resolver mis problemas de sintaxis.

http://www.regexplanet.com/advanced/perl/index.html

Simplemente habría agregado un comentario a una respuesta existente, pero mi reputación aún no está en ese nivel. Espero que esto ayude a alguien.

Con respecto a 4., aún debe asegurarse de que su "código auxiliar de script ficticio" sea en realidad la URL de destino después de que se haya realizado toda la reescritura, ¡o no verá nada!

Un truco similar / relacionado (ver esta pregunta ) es insertar una regla temporal como:

RewriteRule (.*) /show.php?url=$1 [END]

¿Dónde show.phphay un script muy simple que solo muestra su$_GET parámetros (también puede mostrar variables de entorno, si lo desea).

Esto detendrá la reescritura en el punto en que lo inserte en el conjunto de reglas, más bien como un punto de interrupción en un depurador.

Si está utilizando Apache <2.3.9, tendrá que usar [L]en lugar de [END], y puede entonces necesitar agregar:

RewriteRule ^show.php$ - [L]

En la parte superior de su conjunto de reglas, si la URL /show.phpse está reescribiendo.

Algunos errores que observé ocurren al escribir .htaccess

Uso de ^(.*)$repetitivo en múltiples reglas, usando^(.*)$ hace que otras reglas sean impotentes en la mayoría de los casos, ya que coincide con todas las URL en un solo golpe.

Entonces, si estamos usando una regla para esta url sapmle/url, también consumirá esta url sapmle/url/string.

[L] La bandera debe usarse para garantizar que nuestra regla haya procesado.

Debe saber sobre:

Diferencia en% n y $ n

%nse compara durante %{RewriteCond}parte y $ncoincide con %{RewriteRule}parte.

Trabajo de RewriteBase

La directiva RewriteBase especifica el prefijo de URL que se utilizará para las directivas RewriteRule por directorio (htaccess) que sustituyen una ruta relativa.

Esta directiva es necesaria cuando utiliza una ruta relativa en una sustitución en contexto por directorio (htaccess) a menos que se cumpla alguna de las siguientes condiciones:

La solicitud original y la sustitución se encuentran debajo de DocumentRoot (en lugar de ser accesible por otros medios, como Alias). La ruta del sistema de archivos al directorio que contiene la RewriteRule, con el sufijo de la sustitución relativa, también es válida como una ruta URL en el servidor (esto es raro). En Apache HTTP Server 2.4.16 y posterior, esta directiva puede omitirse cuando la solicitud se asigna a través de Alias ​​o mod_userdir.

Si planea escribir más de una sola línea de reglas en .htacesss,
ni siquiera piense en probar uno de esos métodos de corrección para depurarlo.

He desperdiciado días estableciendo múltiples reglas, sin comentarios de los LOG, solo para finalmente rendirme.
Obtuve Apache en mi PC, copié todo el sitio en su HDD y resolví todo el conjunto de reglas, usando los registros, muy rápido.
Luego revisé mis viejas reglas, que han estado funcionando. Vi que realmente no estaban haciendo lo que deseaban. Una bomba de tiempo, dada una dirección ligeramente diferente.

Hay tantas fallas en las reglas de reescritura, que no es algo lógico en absoluto.
Puede poner en funcionamiento Apache en diez minutos, son 10 MB, buena licencia, * NIX / WIN / MAC listo, incluso sin instalación.
Además, verifique las líneas de encabezado de su servidor y obtenga la misma versión de Apache de su archivo si es antigua. Mi OP todavía está en 2.0; Muchas cosas no son compatibles.

Dejaré esto aquí, tal vez detalles obvios, pero me golpeé la cabeza durante horas: tenga cuidado al usarlo %{REQUEST_URI}porque lo que @Krist van Besien dice en su respuesta es totalmente correcto, pero no para la cadena REQUEST_URI , porque la salida de esto TestString comienza con a /. Así que ten cuidado:

RewriteCond %{REQUEST_URI} ^/assets/$  
                            ^
                            | check this pesky fella right here if missing

(Similar a la idea de Doin) Para mostrar lo que se está haciendo coincidir, utilizo este código

$keys = array_keys($_GET);
foreach($keys as $i=>$key){
    echo "$i => $key <br>";
}

Guárdelo en r.php en la raíz del servidor y luego haga algunas pruebas en .htaccess
Por ejemplo, quiero hacer coincidir las URL que no comienzan con un prefijo de idioma

RewriteRule ^(?!(en|de)/)(.*)$ /r.php?$1&$2 [L] #$1&$2&...
RewriteRule ^(.*)$ /r.php?nomatch [L] #report nomatch and exit

Como lo señaló @JCastell, el probador en línea hace un buen trabajo al probar redireccionamientos individuales contra un archivo .htaccess. Sin embargo, más interesante es la API expuesta que se puede usar para probar por lotes una lista de URL utilizando un objeto json. Sin embargo, para hacerlo más útil, he escrito un pequeño archivo de script bash que hace uso de curl y jq para enviar una lista de direcciones URL y analizar la respuesta json en una salida con formato CSV con el número de línea y la regla coincidentes en el archivo htaccess junto con la URL redirigida, lo que hace que sea bastante útil comparar una lista de URL en una hoja de cálculo y determinar rápidamente qué reglas no funcionan.

Si está trabajando con url, es posible que desee comprobar si "Habilita Mod Rewrite"