Conseils pour le débogage .htaccess règles de réécriture

Question

De nombreuses affiches ont des problèmes de débogage leur RewriteRule et RewriteCond instructions à l'intérieur de leur .htaccess fichiers. La plupart de ces derniers sont à l'aide d'un service d'hébergement mutualisé et n'ont donc pas accès à la racine du serveur de configuration. Ils ne peuvent pas éviter d'utiliser des .htaccess fichiers pour la réécriture et ne peut pas permettre à un RewriteLogLevel" comme de nombreux répondants suggèrent. Il y a aussi beaucoup d' .htaccess-spécifiques, les pièges et les contraintes ne sont pas couverts. La configuration d'un local de la LAMPE de test de pile implique trop de courbe d'apprentissage pour la plupart.

Donc, mon Q ici est de savoir comment nous recommandons qu'ils déboguer leurs règles elles-mêmes. J'ai quelques suggestions ci-dessous. D'autres suggestions seraient appréciées.

1. Comprendre que le mod_rewrite moteur parcourt .htaccess fichiers. Le moteur tourne 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
   

   Si vos règles seront exécutés à plusieurs reprises et si vous changez le chemin de l'URI ensuite, il peut finir par l'exécution d'autres .htacessfichiers s'ils existent. Donc, assurez-vous de mettre fin à cette boucle, si nécessaire en ajoutant des RewriteCond d'arrêter les règles de tir. Également supprimer un niveau inférieur .htaccess jeux de règles de réécriture, sauf si explicitement l'intention de l'utiliser multi-niveau jeux de règles.

2. Assurez-vous que la syntaxe de chaque Regexp est correct par test par rapport à un ensemble de modèles de test pour vous assurer que c'est une syntaxe valide et fait ce que vous avez l'intention avec un éventail de test Uri. Voir la réponse ci-dessous pour plus de détails.

3. Construire vos règles progressivement dans un répertoire de test. Vous pouvez faire usage de la "exécuter le plus profond de l' .htaccess le fichier sur le chemin d'accès à la fonctionnalité" pour définir un répertoire de test (arbre) et de déboguer des jeux de règles ici sans vissage vos principales règles et l'arrêt de votre site de travail. Vous devez les ajouter un à un moment parce que c'est la seule façon de localiser les défaillances des différentes règles.

4. Utiliser un mannequin script de stub pour vider le serveur et les variables d'environnement. (Voir Listing 2)Si votre application utilise, disons, blog/index.php ensuite, vous pouvez copier ce en test/blog/index.php et l'utiliser pour l'essai de votre blog les règles dans l' test sous-répertoire. Vous pouvez également utiliser des variables d'environnement pour s'assurer que le moteur de réécriture dans l'interprétation des chaînes de substitution correctement, par exemple

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

   et regarder pour ces REDIRECT_* variables dans le phpinfo de vidage. BTW, j'ai utilisé celui-ci et de découvrir sur mon site que j'ai dû utiliser %{ENV:DOCUMENT_ROOT_REAL} à la place. Dans le cas de redirecteur boucle REDIRECT_REDIRECT_* liste des variables de la passe précédente. Etc..

5. Assurez-vous que vous n'avez pas de se faire mordre par votre cache de navigateur incorrecte des redirections 301. Voir la réponse ci-dessous. Merci à Ulrich Palha pour cela.

6. Le moteur de réécriture semble sensible à la cascade de règles au sein d'un .htaccess contexte, (c'est là un RewriteRule résultats dans une substitution, et cela tombe bien que d'autres règles), j'ai trouvé des bugs avec les sous-requêtes (1), et incorrectes PATH_INFO de traitement, ce qui peut souvent être empêché par l'utilisation de la [NS], [L] et [PT] les drapeaux.

Plus de commentaire ou des suggestions?

Listing 1 -- phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

Answer 1

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

1. L'utilisation d'un Faux agent utilisateur

Lors de l'essai d'une nouvelle règle, d'ajouter une condition à exécuter uniquement avec un fake user-agent que vous allez utiliser pour vos demandes. De cette façon, il ne sera pas affecter n'importe qui d'autre sur votre site.

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 vous utilisez Firefox, vous pouvez utiliser le User Agent Switcher pour créer le faux chaîne de l'agent utilisateur et de test.

2. Ne pas utiliser 301 jusqu'à ce que vous avez terminé le test

J'ai vu tant de postes où les gens sont toujours tester leurs règlements et ils sont à l'aide de 301. NE PAS.

Si vous n'êtes pas en utilisant la proposition 1 sur votre site, non seulement vous, mais tous les visiteurs de votre site d'être touchés par le 301.

Rappelez-vous qu'ils sont permanents, et de manière agressive mise en cache par votre navigateur. Utiliser un 302 au lieu de cela jusqu'à ce que vous êtes sûr, puis de le changer pour un 301.

3. Rappelez-vous que les 301 sont énergiquement mis en cache dans votre navigateur

Si votre règle ne fonctionne pas et il semble juste pour vous, et vous n'étiez pas à l'aide de suggestions 1 et 2, puis re-test après l'effacer le cache de votre navigateur ou en navigation privée.

4. Utiliser un HTTP outil de Capture d'

Utiliser un HTTP outil de capture comme Violoniste à voir le réel le trafic HTTP entre votre navigateur et le serveur.

Tandis que d'autres pourraient dire que votre site does not look right, vous pourriez voir et de faire rapport all of the images, css and js are returning 404 errors, rapidement circonscrire le problème.

Alors que d'autres rapports que vous started at URL A and ended at URL C,, vous serez en mesure de 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 le but ultime, vous savez que c'est mauvais pour le RÉFÉRENCEMENT et doit être corrigé.

Vous serez en mesure de voir les en-têtes de cache qui ont été mis sur le côté serveur, la relecture des demandes, de modifier les en-têtes de requête pour tester ....

---

Answer 2

Tests de réécriture en ligne .htaccess

http://htaccess.madewithlove.be/

J'ai trouvé ce Googling pour l'aide de RegEx, il m'a sauvé beaucoup de temps d'avoir à télécharger de nouveaux fichiers .htaccess chaque fois que je fais une petite modification.

Answer 3

N'oubliez pas que dans les fichiers .htaccess, il s'agit d'une URL relative qui correspond.

Dans un fichier .htaccess, le RewriteRule suivant ne correspondra jamais:

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

Answer 4

Assurez-vous que la syntaxe de chaque Regexp est correct

par test par rapport à un ensemble de modèles de test pour vous assurer que c'est une syntaxe valide et fait ce que vous avez l'intention avec un éventail de test Uri.

Voir regexpCheck.php ci-dessous un script simple que vous pouvez ajouter à un privé/répertoire test dans votre site pour vous aider à le faire. J'ai gardé ce bref plutôt que de jolie. Juste après ce dans un fichier regexpCheck.php dans un répertoire de test pour l'utiliser sur votre site web. Cela vous aidera à construire toutes les regexp et de le tester contre une liste de cas de tests, comme vous le faites. Je suis en utilisant le PHP moteur PCRE ici, mais ayant eu un coup d'oeil à la source d'Apache, ce qui est essentiellement identique à celui utilisé dans Apache. Il y a beaucoup de HowTos et des tutoriels qui fournissent des modèles et peuvent vous aider à construire votre regexp compétences.

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>

Answer 5

Un d'une couple d'heures que j'ai gaspillé:

Si vous avez appliqué toutes ces astuces et que vous n'obtenez 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 redirige.

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