Comment utiliser : Testeur et validateur .htaccess
- Collez votre fichier
.htaccess(ou cliquez sur Tester les règles dans le générateur .htaccess). - Consultez le panneau de validation : il signale les erreurs qui provoqueraient une erreur 500, ainsi que les avertissements pour les règles qui ne correspondent jamais.
- Saisissez une URL de requête pour la simuler : chaque condition et chaque règle est évaluée, puis la redirection ou la réécriture finale est affichée.
- Listez les fichiers et répertoires existants pour tester les conditions
-fet-d.
Ce que contrôle le validateur
- Directives inconnues et fautes de frappe : Apache répond à toute directive inconnue dans .htaccess par une erreur 500 Internal Server Error.
- Directives réservées au serveur, comme
ServerName,<VirtualHost>ou<Directory>, qui ne sont pas autorisées dans .htaccess. - Conteneurs non équilibrés : un
<IfModule>ou un<FilesMatch>qui n’est jamais fermé. - Expressions régulières invalides et indicateurs inconnus pour
RewriteRule/RewriteCond. - Problèmes de logique : motifs commençant par
^/(ils ne correspondent jamais dans .htaccess), redirections sansL, conditions sans règle, règles placées avantRewriteEngine On. - Compatibilité :
Order/Allow/Denyd’Apache 2.2,php_valuesur les hébergements PHP-FPM, syntaxeOptionsmélangée.
Fonctionnement de la simulation de réécriture
Comme Apache, le testeur retire la barre oblique initiale du chemin, évalue chaque RewriteRule dans l’ordre, vérifie ses lignes RewriteCond (avec [OR] et [NC]), remplace les rétroréférences $1 et %1 ainsi que les variables serveur comme %{HTTP_HOST}, %{HTTPS}, %{REQUEST_URI} et %{QUERY_STRING}, et applique des indicateurs comme R=301, L, QSA, F et G. Après une réécriture interne, il relance les règles, comme le fait Apache dans un contexte par répertoire. Redirect et RedirectMatch sont aussi testées.
Limites
Le simulateur utilise les expressions régulières JavaScript, qui correspondent à PCRE pour presque tous les motifs .htaccess. Il ne peut pas connaître le système de fichiers de votre serveur (listez les fichiers pour les tests -f/-d), RewriteMap, l’environnement défini par d’autres modules, ni l’ordre d’exécution de mod_alias et mod_rewrite sur votre serveur. Vérifiez toujours avec une requête réelle : le vérificateur de redirections affiche la chaîne de redirection en direct.
Créez un nouveau fichier avec le générateur .htaccess, et testez en détail les expressions régulières avec le testeur de regex.
Aussi recherché comme : testeur htaccess, validateur htaccess, tester règles de réécriture, vérifier syntaxe htaccess, testeur mod_rewrite, vérificateur htaccess, tester rewriterule, erreur 500 htaccess.
Outils complémentaires : Testeur et validateur .htaccess
- Générateur htpasswd — Générez des lignes utilisateur:hash pour l’authentification HTTP Basic dans Apache, Nginx, Traefik et Caddy, avec bcrypt par défaut et aucune donnée envoyée à un serveur.
- Codes de statut HTTP — Tous les codes de réponse HTTP standard expliqués simplement, avec le moment où les utiliser et leur effet sur le référencement.
- Validateur YAML — Collez un fichier Docker Compose, un manifeste Kubernetes, un workflow GitHub Actions ou tout autre YAML pour localiser les erreurs, repérer les pièges courants et obtenir une version proprement formatée.
- Générateur YAML Kubernetes — Renseignez le nom, l’image et le port de votre application pour obtenir du YAML Kubernetes prêt pour la production : un Deployment avec sondes, limites de ressources et contexte de sécurité renforcé, ainsi que le Service, l’Ingress avec TLS, le ConfigMap, le Secret et le HorizontalPodAutoscaler que vous cochez, le tout dans un seul fichier prêt pour kubectl apply.
Questions fréquentes
Comment trouver la ligne à l’origine d’une erreur 500 ?
Pourquoi ma RewriteRule ^/page$ ne correspond-elle jamais ?
^page$ à la place de ^/page$.