De nombreuses affiches ont des problèmes pour déboguer leurs instructions RewriteRule et RewriteCond dans leurs .htaccessfichiers. La plupart d'entre eux utilisent un service d'hébergement partagé et n'ont donc pas accès à la configuration du serveur racine. Ils ne peuvent pas éviter d'utiliser des .htaccessfichiers pour la réécriture et ne peuvent pas activer un RewriteLogLevel "comme le suggèrent de nombreux répondants. De plus, il existe de nombreux .htaccesspièges et contraintes spécifiques qui ne sont pas bien couverts. La configuration d'une pile LAMP de test locale implique trop de courbe d'apprentissage pour la plupart .

Donc, mon Q ici est de savoir comment recommanderions-nous de déboguer leurs règles eux-mêmes . Je donne quelques suggestions ci-dessous. D'autres suggestions seraient appréciées.

1. Comprenez que le moteur mod_rewrite parcourt les .htaccessfichiers . Le moteur exécute cette boucle:

   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
   

   Ainsi, vos règles seront exécutées à plusieurs reprises et si vous modifiez le chemin URI, il peut finir par exécuter d'autres .htaccessfichiers s'ils existent. Assurez-vous donc de terminer cette boucle, si nécessaire en ajoutant des RewriteCondrègles supplémentaires pour arrêter le tir. Supprimez également tous les ensembles de règles de .htaccessréécriture de niveau inférieur, sauf si vous avez l'intention explicite d'utiliser des ensembles de règles à plusieurs niveaux.

2. Assurez-vous que la syntaxe de chaque expression rationnelle est correcte en testant par rapport à un ensemble de modèles de test pour vous assurer qu'il s'agit d'une syntaxe valide et fait ce que vous souhaitez avec une gamme complète d'URI de test. Voir la réponse ci-dessous pour plus de détails.

3. Créez vos règles de manière incrémentielle dans un répertoire de test. Vous pouvez utiliser la fonction «exécuter le .htaccessfichier le plus profond sur le chemin» pour configurer un répertoire de test (arborescence) distinct et déboguer les ensembles de règles ici sans bousiller vos règles principales et arrêter le fonctionnement de votre site. Vous devez les ajouter un à la fois car c'est le seul moyen de localiser les échecs des règles individuelles.

4. Utilisez un stub factice pour vider les variables de serveur et d'environnement . (Voir Listing 2 ) Si votre application utilise, disons, blog/index.phpvous pouvez le copier test/blog/index.phpet l'utiliser pour tester les règles de votre blog dans le testsous - répertoire. Vous pouvez également utiliser des variables d'environnement pour vous assurer que le moteur de réécriture interprète correctement les chaînes de substitution, par exemple

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

   et recherchez ces variables REDIRECT_ * dans le vidage phpinfo. BTW, j'ai utilisé celui-ci et découvert sur mon site que je devais utiliser à la %{ENV:DOCUMENT_ROOT_REAL}place. Dans le cas d'une boucle de redirection, les variables REDIRECT_REDIRECT_ * listent la passe précédente. Etc..

5. Assurez-vous que votre navigateur ne mord pas en mettant en cache des redirections 301 incorrectes . Voir la réponse ci-dessous . Mes remerciements à Ulrich Palha pour cela.

6. Le moteur de réécriture semble sensible aux règles en cascade dans un .htaccesscontexte, (c'est là que cela RewriteRuleentraîne une substitution et cela revient à d'autres règles), car j'ai trouvé des bogues avec des sous-demandes internes (1) et un traitement PATH_INFO incorrect qui peut souvent be empêche l'utilisation des drapeaux [NS], [L] et [PT].

Avez-vous d'autres commentaires ou suggestions?

Listing 1 - phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

Voici quelques conseils supplémentaires sur les règles de test qui peuvent faciliter le débogage pour les utilisateurs sur l'hébergement partagé

1. Utilisez un agent de faux utilisateurs

Lors du test d'une nouvelle règle, ajoutez une condition pour l'exécuter uniquement avec un fakeagent utilisateur que vous utiliserez pour vos demandes. De cette façon, cela n'affectera personne d'autre sur votre site.

par exemple

#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 vous utilisez Firefox, vous pouvez utiliser le sélecteur d'agent utilisateur pour créer la fausse chaîne d'agent utilisateur et tester.

2. N'utilisez pas 301 avant d'avoir terminé les tests

J'ai vu tellement de messages où les gens testent encore leurs règles et utilisent des 301. PAS .

Si vous n'utilisez pas la suggestion 1 sur votre site, non seulement vous, mais toute personne visitant votre site à ce moment-là sera affectée par le 301.

N'oubliez pas qu'ils sont permanents et agressivement mis en cache par votre navigateur. Utilisez un 302 à la place jusqu'à ce que vous soyez sûr, puis changez-le en 301.

3. N'oubliez pas que les 301 sont agressivement mis en cache dans votre navigateur

Si votre règle ne fonctionne pas et qu'elle vous semble correcte et que vous n'utilisiez pas les suggestions 1 et 2, testez à nouveau après avoir effacé le cache de votre navigateur ou en navigation privée.

4. Utilisez un outil de capture HTTP

Utilisez un outil de capture HTTP comme Fiddler pour voir le trafic HTTP réel entre votre navigateur et le serveur.

Alors que d'autres pourraient dire que c'est le cas site does not look right, vous pouvez plutôt le voir et le signaler all of the images, css and js are returning 404 errors, réduisant rapidement le problème.

Alors que d'autres vous signaleront started at URL A and ended at URL C, vous pourrez voir qu'ils ont commencé à URL A, were 302 redirected to URL B and 301 redirected to URL C. Même si l'URL C était l'objectif ultime, vous saurez que cela est mauvais pour le référencement et doit être corrigé.

Vous pourrez voir les en-têtes de cache qui ont été définis côté serveur, relire les requêtes, modifier les en-têtes de requête à tester ....

Test de réécriture .htaccess en ligne

J'ai trouvé cette aide sur Google pour RegEx, cela m'a fait gagner beaucoup de temps de devoir télécharger de nouveaux .htaccessfichiers chaque fois que je fais une petite modification.

du site:

testeur htaccess

Pour tester vos règles de réécriture htaccess, remplissez simplement l'URL à laquelle vous appliquez les règles, placez le contenu de votre htaccess sur la plus grande zone de saisie et appuyez sur le bouton "Vérifier maintenant".

N'oubliez pas que dans les fichiers .htaccess, c'est une URL relative qui correspond.

Dans un fichier .htaccess, la RewriteRule suivante ne correspondra jamais:

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

Assurez-vous que la syntaxe de chaque expression rationnelle est correcte

en testant par rapport à un ensemble de modèles de test pour vous assurer qu'il s'agit d'une syntaxe valide et fait ce que vous souhaitez avec une gamme complète d'URI de test.

Voir regexpCheck.php ci-dessous pour un script simple que vous pouvez ajouter à un répertoire privé / test de votre site pour vous y aider. J'ai gardé ce bref plutôt que joli. Il suffit de le coller dans un fichier regexpCheck.phpdans un répertoire de test pour l'utiliser sur votre site Web. Cela vous aidera à créer une expression rationnelle et à la tester par rapport à une liste de cas de test au fur et à mesure. J'utilise le moteur PHP PCRE ici, mais après avoir jeté un œil à la source Apache, celle-ci est fondamentalement identique à celle utilisée dans Apache. Il existe de nombreux HowTos et tutoriels qui fournissent des modèles et peuvent vous aider à développer vos compétences d'expression rationnelle.

Listing 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>

Assurez-vous d'utiliser le signe pourcentage devant les variables, pas le signe dollar.

Il est %{HTTP_HOST}, non ${HTTP_HOST} . Il n'y aura rien dans le error_log, il n'y aura pas d'erreurs internes au serveur, votre expression régulière est toujours correcte, la règle ne correspondra tout simplement pas. C'est vraiment hideux si vous travaillez beaucoup avec les modèles django / genshi et que vous avez ${}une substitution de variable dans la mémoire musculaire.

Un de quelques heures que j'ai perdu:

Si vous avez appliqué tous ces conseils et que vous ne faites que 500 erreurs parce que vous n'avez pas accès au journal des erreurs du serveur, le problème n'est peut-être pas dans le fichier .htaccess mais dans les fichiers vers lesquels il est redirigé.

Après avoir résolu mon problème .htaccess, j'ai passé deux heures de plus à le résoudre, même si j'avais simplement oublié certaines autorisations.

Définissez des variables d'environnement et utilisez des en-têtes pour les recevoir:

Vous pouvez créer de nouvelles variables d'environnement avec des lignes RewriteRule, comme mentionné par OP:

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

Mais si vous ne pouvez pas faire fonctionner un script côté serveur, comment pouvez-vous alors lire cette variable d'environnement? Une solution consiste à définir un en-tête:

Header set TEST_FOOBAR "%{REDIRECT_TEST0}e"

La valeur accepte les spécificateurs de format , y compris le %{NAME}espécificateur pour les variables d'environnement (n'oubliez pas le e minuscule). Parfois, vous devrez ajouter le REDIRECT_préfixe, mais je n'ai pas déterminé quand le préfixe est ajouté et quand il ne le fait pas.

Si vous créez des redirections, testez avec curl pour éviter les problèmes de mise en cache du navigateur. Utilisez -I pour récupérer uniquement les en-têtes http. Utilisez -L pour suivre toutes les redirections.

J'ai trouvé cette question en essayant de déboguer mes problèmes de mod_rewrite, et elle contient certainement des conseils utiles. Mais à la fin, la chose la plus importante est de vous assurer que votre syntaxe regex est correcte. En raison de problèmes avec ma propre syntaxe RE, l'installation du script regexpCheck.php n'était pas une option viable.

Mais comme Apache utilise des expressions régulières compatibles Perl (PCRE), tout outil qui aide à écrire des PCRE devrait aider. J'ai utilisé l'outil de RegexPlanet avec des RE Java et Javascript dans le passé, et j'ai été heureux de constater qu'ils prennent également en charge Perl.

Tapez simplement votre expression régulière et un ou plusieurs exemples d'URL, et il vous dira si la regex correspond (un "1" dans la colonne "~ =") et, le cas échéant, les groupes correspondants (les nombres dans le "split" La colonne correspondra aux nombres qu'Apache attend, par exemple 1 $, 2 $, etc.) pour chaque URL. Ils prétendent que le support PCRE est "en version bêta", mais c'était exactement ce dont j'avais besoin pour résoudre mes problèmes de syntaxe.

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

J'aurais simplement ajouté un commentaire à une réponse existante mais ma réputation n'est pas encore à ce niveau. J'espère que cela aide quelqu'un.

En ce qui concerne 4., vous devez toujours vous assurer que votre "talon de script factice" est bien l'URL cible une fois la réécriture terminée, sinon vous ne verrez rien!

Une astuce similaire / connexe (voir cette question ) consiste à insérer une règle temporaire telle que:

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

Où show.phpest un script très simple qui affiche simplement ses $_GETparamètres (vous pouvez également afficher des variables d'environnement, si vous le souhaitez).

Cela arrêtera la réécriture au moment où vous l'insérez dans l'ensemble de règles, plutôt comme un point d'arrêt dans un débogueur.

Si vous utilisez Apache <2.3.9, vous devrez utiliser [L]plutôt que [END], et vous devrez alors peut- être ajouter:

RewriteRule ^show.php$ - [L]

Tout en haut de votre ensemble de règles, si l'URL /show.phpest elle-même en cours de réécriture.

Certaines erreurs que j'ai observées se produisent lors de l'écriture .htaccess

L'utilisation ^(.*)$répétitive de plusieurs règles, l'utilisation ^(.*)$entraîne l'impuissance d'autres règles dans la plupart des cas, car elle correspond à toutes les URL en un seul coup.

Donc, si nous utilisons la règle pour cette URL, sapmle/urlelle consommera également cette URL sapmle/url/string.

[L] L'indicateur doit être utilisé pour garantir que notre règle a terminé le traitement.

Devrait savoir:

Différence en% n et $ n

%nest apparié pendant la %{RewriteCond}partie et $ncorrespond à la %{RewriteRule}partie.

Fonctionnement de RewriteBase

La directive RewriteBase spécifie le préfixe d'URL à utiliser pour les directives RewriteRule par répertoire (htaccess) qui remplacent un chemin relatif.

Cette directive est requise lorsque vous utilisez un chemin relatif dans une substitution dans un contexte par répertoire (htaccess), sauf si l'une des conditions suivantes est remplie:

La demande d'origine et la substitution se trouvent sous DocumentRoot (par opposition à accessibles par d'autres moyens, tels que Alias). Le chemin du système de fichiers vers le répertoire contenant la RewriteRule, suffixé par la substitution relative, est également valide comme chemin d'URL sur le serveur (c'est rare). Dans Apache HTTP Server 2.4.16 et versions ultérieures, cette directive peut être omise lorsque la demande est mappée via Alias ​​ou mod_userdir.

Si vous prévoyez d'écrire plus d'une ligne de règles dans .htacesss,
ne pensez même pas à essayer l'une de ces méthodes de correction à chaud pour la déboguer.

J'ai perdu des jours à définir plusieurs règles, sans commentaires des journaux, pour finalement abandonner.
J'ai installé Apache sur mon PC, j'ai copié tout le site sur son disque dur et j'ai trié l'ensemble des règles, en utilisant les journaux, très rapidement.
Ensuite, j'ai revu mes anciennes règles, qui fonctionnaient. J'ai vu qu'ils ne faisaient pas vraiment ce qui était souhaité. Une bombe à retardement, étant donné une adresse légèrement différente.

Il y a tellement de pièges dans les règles de réécriture, ce n'est pas du tout logique.
Vous pouvez obtenir Apache opérationnel en dix minutes, il est de 10 Mo, bonne licence, prêt pour NIX / WIN / MAC, même sans installation.
Vérifiez également les lignes d'en-tête de votre serveur et obtenez la même version d'Apache à partir de leurs archives si elle est ancienne. Mon OP est toujours sur 2.0; beaucoup de choses ne sont pas prises en charge.

Je vais laisser cela ici, peut-être un détail évident, mais ça m'a fait me cogner la tête pendant des heures: soyez prudent en utilisant %{REQUEST_URI}parce que ce que @Krist van Besien dit dans sa réponse est tout à fait juste, mais pas pour la chaîne REQUEST_URI , parce que le résultat de cette TestString commence par un /. Alors faites attention:

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

(Similaire à l'idée de Doin) Pour montrer ce qui est apparié, j'utilise ce code

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

Enregistrez-le dans r.php à la racine du serveur, puis faites des tests en .htaccess
Par exemple, je veux faire correspondre les URL qui ne commencent pas par un préfixe de langue

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

comme l'a souligné @JCastell, le testeur en ligne fait un bon travail de test des redirections individuelles par rapport à un fichier .htaccess. Cependant, plus intéressante est l' api exposée qui peut être utilisée pour tester par lots une liste d'urls à l'aide d'un objet json. Cependant, pour le rendre plus utile, j'ai écrit un petit fichier de script bash qui utilise curl et jq pour soumettre une liste d'URL et analyser la réponse json dans une sortie au format CSV avec le numéro de ligne et la règle correspondant dans le fichier htaccess avec l'URL redirigée, ce qui rend très pratique la comparaison d'une liste d'URL dans une feuille de calcul et la détermination rapide des règles qui ne fonctionnent pas.

Si vous travaillez avec l'URL, vous voudrez peut-être vérifier si vous "Activez la réécriture du mod"