Consejos para depurar las reglas de reescritura de .htaccess

Muchos carteles tienen problemas para depurar sus declaraciones RewriteRule y RewriteCond dentro de su .htaccess archivos. La mayoría de ellos utilizan un servicio de alojamiento compartido y, por lo tanto, no tienen acceso a la configuración del servidor raíz. No pueden evitar usar .htaccess archivos para reescribir y no pueden habilitar un RewriteLogLevel "como sugieren muchos encuestados. También hay muchos .htaccess-Las dificultades y limitaciones específicas no se tratan bien. La configuración de una pila de LAMP de prueba local implica demasiada curva de aprendizaje para la mayoría.

Entonces mi pregunta aquí es cómo recomendaríamos que depurar sus reglas sí mismos. Proporciono algunas sugerencias a continuación. Se agradecerían otras sugerencias.

  1. Comprenda que el motor mod_rewrite pasa por .htaccess archivos. 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 URI, puede terminar ejecutando otras .htaccessarchivos si existen. Así que asegúrese de terminar este ciclo, si es necesario agregando extra RewriteCond para detener la activación de las reglas. También elimine cualquier nivel inferior .htaccess reescriba los conjuntos de reglas 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 pretenda con una gama completa de URI de prueba. Ver Responda abajo para más información.

  3. Cree sus reglas de forma incremental en un directorio de prueba. Puede hacer uso de la opción "ejecutar la más profunda .htaccess file on the path feature "para configurar un directorio de prueba (árbol) separado y depurar conjuntos de reglas aquí sin arruinar las reglas principales y detener el funcionamiento de su sitio. Debe agregarlos uno a la vez porque esta es la única forma de localizar fallas a las reglas individuales.

  4. Utilice un código auxiliar de script ficticio para descargar las variables de entorno y del servidor. (Véase Listado 2) Si su aplicación usa, digamos, blog/index.php entonces puedes copiar esto en test/blog/index.php y utilícelo para probar las reglas de su blog en el test subdirectorio. También puede utilizar variables de entorno para asegurarse de que el motor de reescritura interprete correctamente las cadenas de sustitución, p. Ej.

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

    y busca estos REDIRECT_ * variables en el volcado phpinfo. Por cierto, usé este y descubrí en mi sitio que tenía que usar %{ENV:DOCUMENT_ROOT_REAL} en lugar de. En el caso de un redirector en bucle REDIRECT_REDIRECT_ * las variables enumeran la pasada anterior. Etc.

  5. Asegúrese de que su navegador no lo muerda al almacenar en caché redireccionamientos 301 incorrectos. Ver Responda abajo. Mi agradecimiento a Ulrich Palha para esto.

  6. El motor de reescritura parece sensible a las reglas en cascada dentro de un .htaccess contexto, (que es donde un RewriteRule da como resultado una sustitución y esto depende de otras reglas), ya que encontré errores con sub-solicitudes internas (1), e incorrecto PATH_INFO procesamiento que a menudo se puede evitar 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);

preguntado el 05 de febrero de 12 a las 17:02

Estos son buenos ... Quizás debería pasarlos de la pregunta a una respuesta. -

@ w00t, he separado el verificador de expresiones regulares según su sugerencia porque quiero referirlo por enlace en otras respuestas. -

Es posible que desee agregar el diagrama de flujo de control de los documentos a tu primera sugerencia. En mi opinión, es mucho más fácil de comprender que cualquier pseudocódigo o explicación, y esta es realmente la parte más negra del vudú de reescritura de mods. -

El número 6 es muy importante. Las reglas de reescritura que se comportan de manera diferente en los archivos de configuración estándar de Apache y en los archivos .htaccess deben atrapar a mucha gente. -

Algo que puede valer la pena agregar a estas sugerencias: pasé algún tiempo depurando un problema con la redirección y no la reescritura. Resulta que lo reescribí en "/ comment" cuando quería "/ comment /". Se estaba reescribiendo a "/ comentario" y luego el servidor estaba haciendo una redirección a "/ comentario /". Comportamiento obvio para aquellos que están acostumbrados a Apache, pero probablemente menos para novatos como yo. -

18 Respuestas

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

1. Utilice un agente de usuario falso

Cuando pruebe una nueva regla, agregue una condición para ejecutarla solo con una fake user-agent que utilizará para sus solicitudes. De esta forma, no afectará a nadie más en su sitio.

e.g.

#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á utilizando Firefox, puede utilizar el Intercambiador de agentes de usuario para crear la cadena de agente de usuario falso y probar.

2. No use 301 hasta que haya terminado la prueba

He visto tantas publicaciones en las que la gente todavía está probando sus reglas y están usando 301. NO.

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á afectado por el 301.

Recuerde que son permanentes y agresivamente almacenados en caché por su navegador. Use un 302 en su lugar hasta que esté seguro, luego cámbielo a un 301.

3. Recuerde que los 301 se almacenan en caché de forma agresiva en su navegador.

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

4. Utilice una herramienta de captura HTTP

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

Mientras que otros pueden decir que tu site does not look right, en su lugar, podría ver e informar que 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ás ver que comenzaron en URL A, were 302 redirected to URL B and 301 redirected to URL C. Incluso si la URL C fuera el objetivo final, sabrá que esto es malo para el SEO y debe corregirse.

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


Respondido 09 Feb 12, 12:02

Ulrich, muchas gracias por esta entrada. Has recogido algunos aspectos que no había pensado en poner en mi lista. En el problema de depuración 301, utilizo Chrome en "Navegación privada" (también conocido como "Modo porno"), ya que esto descarga esta información de estado cuando cierra la ventana. Espero que no le importe que no "acepte" esto, ya que es un punto importante, pero no la mejor respuesta. Gracias de nuevo. :) - TerryE

Para dejarlo claro (lo tiene en su código pero no lo detectó), pero para asegurarse de que está utilizando una redirección 302, no 301, necesita [L,R=302] - icc97

No es necesario especificar explícitamente [L, R=302] acaba de hacer [L,R] el valor predeterminado es 302 - Rahil Wazir

@goodeye, también mire la casilla de verificación "Chrome> Configuración> General> Deshabilitar caché mientras DevTools está abierto". - caracoles

Prueba de reescritura de .htaccess en línea

Encontré este Buscar en Google ayuda de RegEx, me ahorró mucho tiempo de tener que cargar nuevos .htaccess archivos cada vez que hago una pequeña modificación.

desde el sitio:

probador htaccess

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".

Respondido el 20 de junio de 20 a las 10:06

Gracias por el puntero a esta herramienta, que encontré la forma más directa de depurar mi problema. - BobHy

Si tiene acceso ssh a su espacio web, otra opción es cambiar el .htaccess directamente a través del editor en el servidor. - sjas

Deberá ignorar la advertencia ssl porque el certificado del sitio tiene problemas. Pero el sitio sigue ahí. Ésta es la mejor y más sencilla solución. Brinda una visión increíble de lo que está mal y da como resultado la solución del problema RÁPIDO. - Toddmo

Gracias por señalar esta herramienta. Es útil. A veces, depurar el htaccess de apache en sí es muy difícil. Gracias. Muchas gracias - Benyamin Limanto

Se ve bien, primero. Pero echa de menos muchas funciones. Desafortunadamente, no es una herramienta confiable. - Honsa Stunna

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

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

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

Respondido el 21 de junio de 13 a las 08:06

Sí, la cadena se introdujo en una reescrituraRegla es relativo y, por lo tanto, despojado de cualquier /, pero esta eliminación no ocurre para las cadenas de coincidencias ensambladas en RewriteCond. comandos. - TerryE

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, incluyendo la %{NAME}e especificador para variables de entorno (no olvide la e minúscula). A veces, necesitará agregar el REDIRECT_ prefijo, pero no he resuelto cuándo se agrega el prefijo y cuándo no.

Respondido 04 ago 15, 15:08

¿Ha obtenido más información sobre cuándo usar o no el REDIRECT_ ¿prefijo? Además, también veo terminología sobre prefijos en otros contextos (htaccess), pero nunca ha quedado claro exactamente qué significa. ¿Significa que debe nombrar su variable con el prefijo, o agregar el prefijo a su variable nombrada, cuando usa ciertos comandos (pero no otros comandos)? Tu ejemplo es el en el primer que muestra ambas la definición de var y el uso de var, por lo que a partir de esto me inclino a pensar lo último. Los documentos han sido de poca ayuda: suponen que sabemos demasiado y dan muy pocas referencias / enlaces. - sherylhohman

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 pretenda con una gama completa de URI de prueba.

Vea RegexpCheck.php a continuación para obtener una secuencia de comandos simple que puede agregar a un directorio privado / de prueba en su sitio para ayudarlo a hacer esto. He mantenido esto más breve que bonito. Pasa esto en un archivo regexpCheck.php en un directorio de prueba para usarlo en su sitio web. Esto le ayudará a crear cualquier expresión regular y a probarla con una lista de casos de prueba a medida que lo hace. Estoy usando el motor PHP PCRE aquí, pero habiendo echado un vistazo a la fuente de Apache, esta es básicamente idéntica a la 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>

Respondido el 20 de junio de 20 a las 10:06

Nota rápida: import_request_variables quedó obsoleto en PHP 5.3 y se eliminó en 5.4. extract($_GET) junto con extract($_POST) puede realizar la misma función, pero todas las variables necesitarían eliminar el prefijo de su nombre. Fuente: php.net/manual/en/function.import-request-variables.php - jeff lamberto

@watcher, gracias. Actualicé mi versión local para que sea compatible con 5.4 hace un año, pero olvidé cambiar esta publicación. Ahora hecho. - TerryE

oh, incluso después de la edición, no puedo obtener buenos resultados simplemente copiando su código ... pero con los violinistas de expresiones regulares, creo que su herramienta es obsoleta de todos modos. echa un vistazo a estas fantásticas herramientas: Regex101.com or refiddle.com or Regexr.com - software hexerei

@hexereisoftware, esta publicación tiene 3 años, por lo que puede haber problemas sutiles según la versión de PHP que use ahora y la versión de Apache. Sin embargo, hay muchas variantes de expresiones regulares, cada una con diferencias sutiles. Como dije, el código Apache usa un motor PCRE que es muy similar al motor PHP. No estoy seguro de cuáles son las diferencias con las otras variantes como .Net, por lo que aunque su sugerencia de usar un recurso en línea es buena, me quedaría con uno que admita explícitamente la sintaxis de Apache o PHP. :-) - TerryE

Perl sería el más cercano, pero php usa la misma sintaxis: software hexerei

Uno de un par de horas que perdí:

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

Después de haber solucionado mi .htaccess-problem, pasé dos horas más tratando de solucionarlo un poco más, aunque simplemente me había olvidado de algunos permisos.

Respondido 04 Feb 13, 12:02

Utilizo un servicio web de alojamiento de acceso compartido para mi sitio personal, pero lo que he hecho es configurar una máquina virtual de prueba que refleja aproximadamente esto en términos de la configuración de PHP / Apache, directorio de inicio, etc. Sin embargo, debido a que esta máquina virtual en mi administrador Puedo habilitar el registro de reescritura para diagnosticar cualquier dificultad .htaccess asuntos. - TerryE

Asegúrese de utilizar el signo de porcentaje delante de 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 trabaja mucho con plantillas django / genshi y tiene ${} para la sustitución de variables en la memoria muscular.

Respondido el 29 de enero de 13 a las 12:01

Sí, la $ Las variables de sustitución se relacionan con el último patrón RewriteRule y el % los que se relacionan con el último patrón RewriteCond y especiales como% {env: XXX} - TerryE

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

respondido 14 mar '17, 15:03

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.php es 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, como un punto de interrupción en un depurador.

Si está usando Apache <2.3.9, necesitará usar [L] más bien que [END], y usted puede entonces necesito agregar:

RewriteRule ^show.php$ - [L]

En la parte superior de su conjunto de reglas, if la URL /show.php se está reescribiendo en sí mismo.

contestado el 23 de mayo de 17 a las 12:05

Encontré esta pregunta mientras intentaba 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 de RE, la instalación del script regexpCheck.php no era una opción viable.

Pero dado que Apache usa Expresiones regulares compatibles con Perl (PCRE), cualquier herramienta que ayude a escribir PCRE debería ayudar. He usado la herramienta de 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 espera Apache, por ejemplo, $ 1, $ 2, etc.) para cada URL. Afirman que el soporte de 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.

Respondido 01 Feb 13, 22:02

buena herramienta, pero de forma espantosa ... echa un vistazo a estas fantásticas herramientas: Regex101.com or refiddle.com or Regexr.com - software hexerei

Algunos errores que observé ocurren al escribir. .htaccess

Uso de ^(.*)$ repetidamente en múltiples reglas, usando ^(.*)$ hace que otras reglas sean impotentes en la mayoría de los casos, porque coincide con todas las URL en una sola visita.

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


[L] Se debe usar la bandera para garantizar que nuestra regla haya finalizado el procesamiento.


Debería saber sobre:

Diferencia en% n y $ n

%n se empareja durante %{RewriteCond} parte y $n ¿Están los partidos? %{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 usa una ruta relativa en una sustitución en el 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 accesibles por otros medios, como Alias). La ruta del sistema de archivos al directorio que contiene 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 versiones posteriores, esta directiva puede omitirse cuando la solicitud se asigna a través de Alias ​​o mod_userdir.

contestado el 23 de mayo de 17 a las 12:05

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

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

Hay tantas caídas en las reglas de reescritura, que no es una cuestión de lógica pura en absoluto.
Puede poner Apache en funcionamiento en diez minutos, tiene 10 MB, buena licencia, * NIX / WIN / MAC listo, incluso sin instalarlo.
Además, verifique las líneas de encabezado de su servidor y obtenga la misma versión de Apache de su archivo si es anterior. Mi OP todavía está en 2.0; muchas cosas no son compatibles.

Respondido 08 Jul 19, 16:07

papo, he ejecutado servidores dedicados, VPS alojado en ISP y VM privadas dentro de mi estructura de desarrollo, pero sigo usando un servicio de hospedaje compartido para mis dominios públicos y correo electrónico, simplemente porque es más conveniente y rentable usar un sistema completamente administrado. servicio para estos. Este cómo está realmente dirigido a usuarios de servicios compartidos. Configurar una máquina virtual privada para reflejar un servicio compartido por completo es difícil. Sí, si puede, usar una máquina virtual de prueba ayuda, pero sigo usando estos "trucos" de vez en cuando en mi servicio compartido. - TerryE

Estaría de acuerdo con esto if su A se ha enmarcado como una sugerencia alternativa para la depuración mod_rewrite reglas, pero la apertura "ni siquiera lo pienses" es simplemente un mal consejo para los usuarios de servicios compartidos básicos que tienen dificultades para comprender por qué sus htaccess los archivos no funcionan como deberían. - TerryE

Lamento si le pareció que su trabajo de reunir una buena colección de consejos no valía la pena. Yo no quería eso. Créame, me alegró mucho leer y seguir muchos de los consejos que ofrece este hilo. Pero mis reglas se volvieron complicadas lentamente y al final, perdí mucho tiempo simplemente no queriendo pasar por la molestia de instalar un servidor Apache y hacer la depuración como debería hacerse. Más que eso, no aprendí nada, ya que no vi, en los registros, lo que realmente estaba sucediendo. Y están sucediendo muchas cosas. Creo que también es valioso compartir esta experiencia. - Español

para la segunda parte, hay un SI. Mi texto nunca comenzó con 'ni siquiera pienses en'. Veo ahora, esta redacción parece un poco dura, pero todo es cierto. Especialmente para aquellos que son nuevos en esto y luchan por comprender. Los consejos aquí pueden confundirlos, como yo, que todo lo que necesito es una expresión regular sólida, no es tan simple, como su punto 6) PATH_INFO me costó muchos problemas y no es un error como usted dice, sino una característica. Si no desea que se vuelva a agregar, use [DPI]. Pero solo si miras los registros, verás que se agrega allí. Es por eso que, más de una línea, es mejor usar registros: Español

Lo siento @papo, pero mi razón para el voto de -1 fue que creo que este "ni siquiera lo pienses" es un mal consejo, en mi opinión. Si su punto era que "por encima de cierta complejidad, entonces podría resultarle más fácil instalar un servicio Apache local para depurar su .htaccess files ", entonces esto es más equilibrado. Sí, es razonablemente fácil configurar un servicio Apache local, pero lograr que refleje el servicio de alojamiento compartido de un proveedor de servicios puede ser complicado y más allá del nivel de habilidad de muchos usuarios que acaban de usar una configuración de un clic de Wordpress, digamos, y tiene problemas con su .htaccess expediente. - TerryE

Dejaré esto aquí, tal vez un detalle obvio, pero me hizo golpearme la cabeza durante horas: tenga cuidado al usar %{REQUEST_URI} porque que @Krist van Besien decir en su respuesta que es totalmente correcto, pero no para la cadena REQUEST_URI, porque el resultado de esto cadena de prueba comienza con un /. Así que ten cuidado:

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

contestado el 23 de mayo de 17 a las 13:05

(Similar a la idea de Doin) Para mostrar qué coincide, 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

Respondido 14 Oct 13, 05:10

simplemente usar un stub de phpinfo () como mencioné en el punto 4 en mi O / P hace básicamente lo mismo. Buscar QUERY_STRING - TerryE

como señala @JCastell, el probador en línea hace un buen trabajo probando redireccionamientos individuales contra un archivo .htaccess. Sin embargo, más interesante es el abejas expuesto que se puede usar para probar por lotes una lista de URL usando un objeto json. Sin embargo, para que sea más útil, he escrito una pequeña archivo de script bash que hace uso de rizo y jq para enviar una lista de URL y analizar la respuesta json en una salida con formato CSV con el número de línea y la regla que coinciden en el archivo htaccess junto con la URL redirigida, lo que hace que sea muy útil comparar una lista de URL en una hoja de cálculo y determinar rápidamente cuál las reglas no funcionan.

Respondido el 15 de enero de 20 a las 09:01

En caso de que no esté trabajando en un entorno de alojamiento compartido estándar, pero en uno al que tenga acceso de administración (tal vez su entorno de prueba local), asegúrese de que el uso de .htaccess y mod_rewrite están habilitados. Están deshabilitados en una instalación de Apache predeterminada. Y en ese caso, ninguna acción configurada en su .htaccess El archivo funciona, incluso si las expresiones regulares son perfectamente válidas.

Para habilitar el uso de .htaccess:

Encontrar archivo apache2.conf, en Debian / Ubuntu esto está en /etc/apache2, y dentro del archivo la sección

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

y cambia la linea AllowOverride None a AllowOverride All.

Para habilitar el módulo mod_rewrite:

En Debian / Ubuntu, ejecute

sudo a2enmod rewrite

Por cierto, para deshabilitar un módulo, usaría a2dismode en lugar de a2enmode.

Después de realizar los cambios de configuración anteriores, reinicie Apache para que surtan efecto:

sudo systemctl restart apache2

respondido 10 mar '21, 00:03

¡La mejor manera de depurarlo!

Añada LogLevel notice rewrite:trace8 de las personas acusadas injustamente llamadas httpd.conf de apache para registrar todos los avisos de mod_rewrite. Si está en un alojamiento compartido y no tiene acceso a httpd.conf luego pruébelo localmente y cárguelo en el sitio en vivo. Una vez habilitado, esto genera un registro muy grande en muy poco tiempo, significa que no se puede probar en el servidor en vivo de todos modos.

Respondido 09 Oct 21, 19:10

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

Respondido 07 Feb 20, 12:02

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.