Vérifier .htaccess : erreurs et boucles 500

Que fait le vérificateur de .htaccess ?

Il lit un fichier qui existe déjà et répond à trois questions auxquelles un générateur ne peut pas répondre : que fait cette ligne, qu’est-ce qui cloche dedans, et qu’arrive-t-il à cette adresse.

La différence avec les testeurs courants, c’est le sens. La plupart prennent une URL et quelques règles et montrent le résultat. Cela aide quand on a écrit les règles soi-même. Qui hérite d’un fichier qui a grossi a un autre problème : il ne sait pas ce qu’il contient et n’ose donc rien supprimer. C’est pourquoi chaque directive porte ici une phrase en langage ordinaire.

S’y ajoute une évaluation de la difficulté à revenir en arrière. Désactiver le listing de répertoire est réversible à tout moment. Un en-tête HSTS avec preload continue d’agir dans chaque navigateur qui l’a vu une fois, quoi que le serveur envoie ensuite, et sortir de la liste de preload prend des mois. Dans un fichier texte, les deux se ressemblent. Dans la sortie, non.

Pourquoi le serveur répond-il 500 après l’envoi ?

C’est de loin la façon la plus courante de mettre un site hors ligne avec un .htaccess, et la cause est presque toujours la même : une directive dont le module n’est pas chargé.

On s’attendrait à ce qu’Apache passe outre une ligne inconnue. Il ne le fait pas. Il interrompt la requête, pour tout le site, pas seulement pour la règle en cause. Le journal d’erreurs indique alors Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration.

Deux groupes ressortent. Le premier est l’ancien contrôle d’accès d’Apache 2.2 : Order, Allow from, Deny from, Satisfy. Le guide de migration d’Apache nomme Require comme remplaçant depuis 2012, mais les anciennes lignes survivent dans les tutoriels, les réponses de forum et les snippets par défaut de certaines extensions. Le second groupe a besoin d’un module que les offres bon marché omettent souvent : Header a besoin de mod_headers, ExpiresDefault de mod_expires, RewriteRule de mod_rewrite.

La sortie est la même dans les deux cas. Un <IfModule mod_headers.c> autour du bloc transforme l’interruption en saut silencieux. La règle n’a alors plus d’effet, mais le site reste en ligne, et l’en-tête manquant indique où regarder.

Comment reconnaître une boucle de redirection ?

À deux règles qui se nourrissent l’une l’autre. Le cas le plus connu n’a même pas besoin de deux lignes dans votre propre fichier.

Une règle comme RewriteRule ^(.+)/$ /$1 [R=301,L] retire la barre finale. Pour /blog/ elle envoie le visiteur vers /blog. Si blog est un vrai répertoire, mod_dir prend le relais, avec DirectorySlash On par défaut, et remet la barre. Le navigateur suit, la règle s’applique de nouveau, et après une vingtaine de sauts il abandonne avec ERR_TOO_MANY_REDIRECTS. Toute cette partie du site devient inaccessible.

La ligne manquante est RewriteCond %{REQUEST_FILENAME} !-d juste au-dessus de la règle. Elle exclut les vrais répertoires, c’est-à-dire exactement l’ensemble que mod_dir revendique.

Le vérificateur signale cette règle comme une erreur, et l’onglet de la chaîne permet de la reproduire : saisissez le chemin, cochez « existe comme répertoire », et la chaîne montre le saut.

Quelle règle s’applique à une adresse donnée ?

C’est le rôle du test d’URL. Vous saisissez un chemin et l’outil parcourt les règles dans l’ordre, comme le ferait Apache, en affichant chacune qui correspond avec son numéro de ligne.

Deux détails y comptent plus qu’il n’y paraît. D’abord la barre initiale : dans un .htaccess, Apache compare le motif au chemin dont la première barre a déjà été retirée. Une règle copiée d’une configuration serveur avec ^/blog$ ne correspond donc jamais, et on cherche longtemps l’erreur ailleurs.

Ensuite, les deux interrupteurs fichier et répertoire. Des conditions comme %{REQUEST_FILENAME} !-f interrogent le système de fichiers du serveur, qu’un navigateur ne voit pas. Plutôt que de deviner, l’outil vous le demande. Cela rend décidables précisément les règles dont dépendent la plupart des tutoriels.

Là où une condition n’est vraiment pas évaluable, parce qu’elle dépend d’un cookie ou se ramifie avec [OR], la règle n’est pas appliquée et la ligne est marquée « non évaluée ». Le résultat est donc une borne basse : le serveur peut appliquer davantage, mais ce qui est affiché s’applique aussi là-bas.

Que coûte une chaîne de redirections ?

Du temps de chargement, et un peu de référencement. Chaque saut est une requête à part avec sa latence ; sur une connexion mobile lente, trois sauts se remarquent.

Les chaînes se construisent rarement exprès. Elles poussent quand le forçage HTTPS, la canonicalisation www et une vieille redirection se retrouvent dans le même fichier. Chaque règle est correcte isolément ; ensemble elles transforment http://www.exemple.fr/ancien en https://www.exemple.fr/ancien en https://exemple.fr/ancien en https://exemple.fr/nouveau. Trois sauts là où un suffirait.

Le troisième onglet parcourt la chaîne que produit votre propre fichier et compte les sauts. Si une adresse revient sur elle-même, cela apparaît comme une boucle et non comme une redirection qui marche.

Quelles lignes l’outil ne peut-il pas évaluer ?

Tout ce qui sort de la partie qui apparaît dans les vrais fichiers. Sont évaluées les réécritures avec leurs conditions et leurs flags, les redirections via Redirect et RedirectMatch, les en-têtes, les directives d’accès des deux générations d’Apache, le cache, la compression, les pages d’erreur, les options de répertoire et la protection par mot de passe.

Quand autre chose apparaît, une note à côté indique que la ligne n’a pas été évaluée. Elle reste telle quelle dans la liste. C’est volontaire : une vérification qui saute en silence les lignes inconnues finit par délivrer un feu vert qu’elle ne peut pas garantir.

Une limite concerne l’ordre. Apache exécute mod_alias et mod_rewrite en phases séparées, donc Redirect et RewriteRule ne se déroulent pas simplement de haut en bas. Ici, ils sont évalués dans l’ordre du fichier, parce que c’est l’ordre dans lequel une personne le lit. Si un fichier mélange les deux, l’ordre réel peut différer, et c’est indiqué sous le résultat.

Quel est le lien entre le vérificateur et le générateur ?

Ce sont les deux sens de la même chose. Le générateur .htaccess construit un fichier depuis un sélecteur de règles et s’occupe des gardes de module, de la version d’Apache et de l’ordre. Le vérificateur prend un fichier terminé et l’explique.

En pratique, on fait généralement l’aller-retour une fois : parcourir ici le fichier hérité, noter les règles réellement nécessaires, et les monter proprement dans le générateur. Ce qui disparaît, ce sont les lignes recopiées depuis des années qui ne font plus rien.

Si vous changez de serveur, la traduction en syntaxe nginx se trouve dans le générateur de configuration nginx. Pour le fichier de mots de passe visé par AuthUserFile, il y a le générateur .htpasswd.

Le contexte du fichier lui-même est dans la documentation Apache sur .htaccess et dans l’article Wikipédia.