Comprobar .htaccess: errores y bucles 500

¿Qué hace el comprobador de .htaccess?

Lee un fichero que ya existe y responde a tres preguntas que un generador no puede responder: qué hace esta línea, qué falla en ella y qué le ocurre a esta dirección.

La diferencia con los testers habituales es el sentido. La mayoría toma una URL y unas cuantas reglas y muestra el resultado. Eso ayuda cuando uno escribió las reglas. Quien hereda un fichero crecido tiene otro problema: no sabe qué hay dentro y por eso no se atreve a borrar nada. Por eso aquí cada directiva lleva una frase en lenguaje normal.

A eso se añade una valoración de lo difícil que es deshacer una línea. Desactivar el listado de directorios es reversible en cualquier momento. Una cabecera HSTS con preload sigue actuando en todo navegador que la haya visto una vez, envíe lo que envíe el servidor después, y salir de la lista de preload tarda meses. En un fichero de texto ambas se parecen. En la salida no.

¿Por qué responde el servidor con 500 después de subirlo?

Es con diferencia la forma más común de dejar un sitio fuera de línea con un .htaccess, y la causa es casi siempre la misma: una directiva cuyo módulo no está cargado.

Uno esperaría que Apache pasara por alto una línea desconocida. No lo hace. Aborta la petición, y para todo el sitio, no solo para la regla afectada. En el log de errores aparece entonces Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration.

Destacan dos grupos. El primero es el control de acceso antiguo de Apache 2.2: Order, Allow from, Deny from, Satisfy. La guía de actualización de Apache nombra Require como sustituto desde 2012, pero las líneas viejas sobreviven en tutoriales, respuestas de foro y los snippets por defecto de algunos plugins. El segundo grupo necesita un módulo que los planes baratos suelen omitir: Header necesita mod_headers, ExpiresDefault necesita mod_expires, RewriteRule necesita mod_rewrite.

La salida es la misma en ambos casos. Un <IfModule mod_headers.c> alrededor del bloque convierte el aborto en un salto silencioso. La regla deja de tener efecto, pero el sitio sigue en pie, y la cabecera ausente indica dónde mirar.

¿Cómo reconozco un bucle de redirección?

Por dos reglas que se alimentan mutuamente. El caso más conocido ni siquiera necesita dos líneas en el fichero propio.

Una regla como RewriteRule ^(.+)/$ /$1 [R=301,L] quita la barra final. Para /blog/ manda al visitante a /blog. Si blog es un directorio real, entra mod_dir, que trae DirectorySlash On de fábrica, y vuelve a poner la barra. El navegador sigue, la regla aplica otra vez, y tras unos veinte saltos se rinde con ERR_TOO_MANY_REDIRECTS. Toda esa parte del sitio queda inaccesible.

La línea que falta es RewriteCond %{REQUEST_FILENAME} !-d justo encima de la regla. Excluye los directorios reales, que son exactamente los que mod_dir reclama para sí.

El comprobador marca esa regla como error, y la pestaña de la cadena permite reproducirlo: escriba la ruta, marque «existe como directorio» y la cadena muestra el salto.

¿Qué regla aplica a una dirección concreta?

Para eso está la prueba de URL. Escribe una ruta y la herramienta recorre las reglas en orden como haría Apache, mostrando cada una que coincide junto con su número de línea.

Dos detalles importan más de lo que parecen. Primero la barra inicial: dentro de un .htaccess Apache compara el patrón con la ruta a la que ya le ha quitado la primera barra. Una regla copiada de una configuración de servidor con ^/blog$ nunca coincide, y el fallo se busca largo rato en otro sitio.

Segundo, los dos interruptores de fichero y directorio. Condiciones como %{REQUEST_FILENAME} !-f consultan el sistema de ficheros del servidor, que un navegador no ve. En vez de adivinar, la herramienta se lo pregunta a usted. Así se vuelven decidibles justo las reglas de las que dependen la mayoría de los tutoriales.

Donde una condición realmente no se puede evaluar, por depender de una cookie o por ramificar con [OR], la regla no se aplica y la línea se marca como «no evaluada». El resultado es por tanto una cota inferior: en el servidor puede aplicar algo más, pero lo que se muestra también aplica allí.

¿Qué cuesta una cadena de redirecciones?

Tiempo de carga, y algo de posicionamiento. Cada salto es una petición propia con su latencia; en una conexión móvil lenta tres saltos se notan.

Las cadenas rara vez se construyen a propósito. Crecen cuando el forzado de HTTPS, la canonicalización de www y una redirección antigua acaban en el mismo fichero. Cada regla es correcta por separado; juntas convierten http://www.ejemplo.es/viejo en https://www.ejemplo.es/viejo en https://ejemplo.es/viejo en https://ejemplo.es/nuevo. Tres saltos donde bastaría uno.

La tercera pestaña recorre la cadena que produce su propio fichero y cuenta los saltos. Si una dirección vuelve a sí misma, eso aparece como bucle y no como redirección funcional.

¿Qué líneas no puede evaluar la herramienta?

Todo lo que queda fuera de la parte que aparece en ficheros reales. Se evalúan las reescrituras con sus condiciones y flags, las redirecciones vía Redirect y RedirectMatch, las cabeceras, las directivas de acceso de ambas generaciones de Apache, la caché, la compresión, las páginas de error, las opciones de directorio y la protección por contraseña.

Cuando aparece otra cosa, una nota al lado indica que la línea no se evaluó. Se queda tal cual en el listado. Es intencionado: una comprobación que se salta en silencio las líneas desconocidas acaba dando un visto bueno que no puede respaldar.

Hay una limitación de orden. Apache ejecuta mod_alias y mod_rewrite en fases separadas, así que Redirect y RewriteRule no corren simplemente de arriba abajo. Aquí se evalúan en el orden del fichero, porque es el orden en que una persona lo lee. Si un fichero mezcla ambos, el orden real puede diferir, y así se indica bajo el resultado.

¿Cómo se relaciona el comprobador con el generador?

Son los dos sentidos de lo mismo. El generador .htaccess construye un fichero desde un selector de reglas y se ocupa de los guards de módulo, la versión de Apache y el orden. El comprobador toma un fichero terminado y lo explica.

En la práctica se suele hacer el viaje de ida y vuelta una vez: revisar aquí el fichero heredado, anotar las reglas realmente necesarias y montarlas limpias en el generador. Lo que se cae son las líneas que se copian desde hace años y ya no hacen nada.

Si cambia de servidor, la traducción a sintaxis nginx está en el generador de configuración nginx. Para el fichero de contraseñas al que apunta AuthUserFile existe el generador .htpasswd.

El trasfondo del propio fichero está en la documentación de Apache sobre .htaccess y en el artículo de Wikipedia.