Molti poster hanno problemi con il debug delle loro dichiarazioni RewriteRule e RewriteCond all'interno dei propri .htaccessfile. La maggior parte di questi utilizza un servizio di hosting condiviso e pertanto non ha accesso alla configurazione del server principale. Non possono evitare di utilizzare i .htaccessfile per la riscrittura e non possono abilitare un RewriteLogLevel "come suggeriscono molti intervistati. Inoltre ci sono molte .htaccessinsidie ​​specifiche e i vincoli non sono coperti bene. L'impostazione di uno stack LAMP di test locale comporta troppa curva di apprendimento per la maggior parte .

Quindi il mio Q ecco come se consigliamo che il debug loro regole stesse . Fornisco alcuni suggerimenti di seguito. Altri suggerimenti sarebbero apprezzati.

1. Comprendi che il motore mod_rewrite scorre ciclicamente i .htaccessfile . Il motore esegue questo ciclo:

   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
   

   Quindi le tue regole verranno eseguite ripetutamente e se cambi il percorso URI, potrebbe finire per eseguire altri .htaccessfile se esistono. Quindi assicurati di terminare questo ciclo, se necessario aggiungendo ulteriore RewriteCondper fermare l'attivazione delle regole. Eliminare anche qualsiasi .htaccessset di regole di riscrittura di livello inferiore a meno che non si intenda esplicitamente utilizzare set di regole a più livelli.

2. Assicurati che la sintassi di ogni Regexp sia corretta testando una serie di schemi di test per assicurarti che sia una sintassi valida e faccia quello che intendi con una gamma completa di URI di test. Vedi la risposta sotto per maggiori dettagli.

3. Costruisci le tue regole in modo incrementale in una directory di test. È possibile utilizzare il "Esegui il .htaccessfile più profondo sulla funzionalità del percorso" per impostare una directory di test separata (albero) e impostare le regole di debug qui senza rovinare le regole principali e interrompere il funzionamento del sito. Devi aggiungerli uno alla volta perché questo è l'unico modo per localizzare gli errori alle singole regole.

4. Utilizzare uno stub di script fittizio per scaricare le variabili di server e di ambiente . (Vedi il Listato 2 ) Se la tua app utilizza, ad esempio, blog/index.phppuoi copiarla test/blog/index.phpe utilizzarla per testare le regole del tuo blog nella testsottodirectory. È inoltre possibile utilizzare le variabili di ambiente per assicurarsi che il motore di riscrittura interpreti correttamente le stringhe di sostituzione, ad es

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

   e cerca queste variabili REDIRECT_ * nel dump phpinfo. A proposito, ho usato questo e ho scoperto sul mio sito che dovevo usare %{ENV:DOCUMENT_ROOT_REAL}invece. Nel caso del redirector che esegue il looping le variabili REDIRECT_REDIRECT_ * elencano il passaggio precedente. Eccetera..

5. Assicurati di non essere morso dal tuo browser che memorizza nella cache 301 reindirizzamenti errati . Vedi la risposta sotto . I miei ringraziamenti a Ulrich Palha per questo.

6. Il motore di riscrittura sembra sensibile alle regole a cascata all'interno di un .htaccesscontesto (è qui che si RewriteRuletraduce in una sostituzione e questo rientra in ulteriori regole), poiché ho trovato bug con richieste secondarie interne (1) e un'elaborazione PATH_INFO errata che spesso può essere prevenuto dall'uso dei flag [NS], [L] e [PT].

Altri commenti o suggerimenti?

Listato 1 - phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

Ecco alcuni suggerimenti aggiuntivi sui test delle regole che potrebbero facilitare il debug per gli utenti su hosting condiviso

1. Utilizzare un agente utente falso

Quando si verifica una nuova regola, aggiungere una condizione per eseguirla solo con un fakeagente utente che verrà utilizzato per le richieste. In questo modo non influenzerà nessun altro sul tuo sito.

per esempio

#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] 

Se si utilizza Firefox, è possibile utilizzare il commutatore agente utente per creare la stringa e il test dell'agente utente falso.

2. Non utilizzare 301 fino al termine del test

Ho visto così tanti post in cui le persone stanno ancora testando le loro regole e usano 301. NON .

Se non stai utilizzando il suggerimento 1 sul tuo sito, non solo tu, ma chiunque visiterà il tuo sito in quel momento sarà interessato dal 301.

Ricorda che sono permanenti e memorizzati nella cache in modo aggressivo dal tuo browser. Usa invece un 302 fino a quando non sei sicuro, quindi cambialo in un 301.

3. Ricorda che i 301 sono memorizzati nella cache in modo aggressivo nel tuo browser

Se la tua regola non funziona e ti sembra giusto e non stavi utilizzando i suggerimenti 1 e 2, riprova a testare dopo aver svuotato la cache del browser o durante la navigazione privata.

4. Utilizzare uno strumento di acquisizione HTTP

Utilizzare uno strumento di acquisizione HTTP come Fiddler per visualizzare il traffico HTTP effettivo tra il browser e il server.

Mentre altri potrebbero dire che il tuo site does not look right, potresti invece vederlo e segnalarlo all of the images, css and js are returning 404 errors, restringendo rapidamente il problema.

Mentre altri segnaleranno che tu started at URL A and ended at URL C, sarai in grado di vedere che hanno iniziato a URL A, were 302 redirected to URL B and 301 redirected to URL C. Anche se l'URL C fosse l'obiettivo finale, saprai che questo è negativo per il SEO e deve essere risolto.

Sarai in grado di visualizzare le intestazioni della cache impostate sul lato server, riprodurre le richieste, modificare le intestazioni delle richieste da testare ....

Test di riscrittura online .htaccess

Ho trovato questo aiuto su Google per RegEx, mi ha fatto risparmiare un sacco di tempo dal dover caricare nuovi .htaccessfile ogni volta che faccio una piccola modifica.

dal sito:

htaccess tester

Per testare le tue regole di riscrittura di htaccess, inserisci semplicemente l'URL a cui stai applicando le regole, posiziona il contenuto del tuo htaccess nell'area di input più grande e premi il pulsante "Controlla ora".

Non dimenticare che nei file .htaccess è un URL relativo che corrisponde.

In un file .htaccess il seguente RewriteRule non corrisponderà mai:

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

Assicurarsi che la sintassi di ciascun Regexp sia corretta

testando una serie di modelli di test per assicurarsi che sia una sintassi valida e faccia quello che intendi con una gamma completa di URI di test.

Vedi regexpCheck.php di seguito per un semplice script che puoi aggiungere a una directory privata / test nel tuo sito per aiutarti a farlo. Ho tenuto questo breve piuttosto che carino. Basta passarlo in un file regexpCheck.phpin una directory di prova per usarlo sul tuo sito web. Questo ti aiuterà a costruire qualsiasi regexp e testarlo su un elenco di casi di test mentre lo fai. Sto usando il motore PHP PCRE qui, ma avendo dato un'occhiata alla fonte Apache, questo è sostanzialmente identico a quello usato in Apache. Esistono molti tutorial ed esercitazioni che forniscono modelli e possono aiutarti a sviluppare le tue abilità di regexp.

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

Assicurati di utilizzare il segno di percentuale davanti alle variabili, non il simbolo di dollaro.

E ' %{HTTP_HOST}, non è ${HTTP_HOST} . Non ci sarà nulla nel log degli errori, non ci saranno errori del server interno, il tuo regexp è ancora corretto, la regola non corrisponderà. Questo è davvero orribile se lavori molto con i modelli django / genshi e hai ${}una sostituzione variabile nella memoria muscolare.

Uno da un paio d'ore che ho sprecato:

Se hai applicato tutti questi suggerimenti e stai riscontrando solo 500 errori perché non hai accesso al registro degli errori del server, forse il problema non è nel .htaccess ma nei file a cui reindirizza.

Dopo aver risolto il mio problema con .htaccess, ho trascorso altre due ore a cercare di risolverlo un po 'di più, anche se avevo semplicemente dimenticato alcune autorizzazioni.

Imposta le variabili di ambiente e usa le intestazioni per riceverle:

È possibile creare nuove variabili di ambiente con le righe RewriteRule, come indicato da OP:

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

Ma se non riesci a far funzionare uno script sul lato server, come puoi leggere questa variabile d'ambiente? Una soluzione è impostare un'intestazione:

Header set TEST_FOOBAR "%{REDIRECT_TEST0}e"

Il valore accetta gli identificatori di formato , incluso l' %{NAME}eidentificatore per le variabili di ambiente (non dimenticare la e minuscola). A volte, dovrai aggiungere il REDIRECT_prefisso, ma non ho capito quando viene aggiunto il prefisso e quando non lo fa.

Se stai creando reindirizzamenti, prova con l' arricciatura per evitare problemi di memorizzazione nella cache del browser. Utilizzare -I per recuperare solo le intestazioni http. Utilizzare -L per seguire tutti i reindirizzamenti.

Ho trovato questa domanda mentre cercavo di eseguire il debug dei miei problemi mod_rewrite e ha sicuramente dei consigli utili. Ma alla fine la cosa più importante è assicurarsi di avere la sintassi della regex corretta. A causa di problemi con la mia sintassi RE, l'installazione dello script regexpCheck.php non era un'opzione praticabile.

Ma poiché Apache utilizza le espressioni regolari (PCRE) compatibili con Perl, qualsiasi strumento che aiuta a scrivere PCRE dovrebbe aiutare. Ho usato lo strumento RegexPlanet con Java e Javascript RE in passato ed è stato felice di scoprire che supportano anche Perl.

Digita semplicemente la tua espressione regolare e uno o più URL di esempio e ti dirà se la regex corrisponde (un "1" nella colonna "~ =") e, se applicabile, tutti i gruppi corrispondenti (i numeri nella "divisione" colonna corrisponderà ai numeri previsti da Apache, ad esempio $ 1, $ 2 ecc.) per ciascun URL. Sostengono che il supporto PCRE è "in beta", ma era proprio quello di cui avevo bisogno per risolvere i miei problemi di sintassi.

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

Avrei semplicemente aggiunto un commento a una risposta esistente ma la mia reputazione non è ancora a quel livello. Spero che questo aiuti qualcuno.

Per quanto riguarda 4., devi comunque assicurarti che il tuo "stub di script fittizio" sia in realtà l'URL di destinazione dopo aver eseguito tutta la riscrittura, altrimenti non vedrai nulla!

Un trucco simile / correlato (vedi questa domanda ) è quello di inserire una regola temporanea come:

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

Dov'è show.phpuno script molto semplice che mostra solo il suo$_GET parametri (puoi anche visualizzare le variabili di ambiente, se vuoi).

Ciò interromperà la riscrittura nel punto in cui lo si inserisce nel set di regole, piuttosto come un punto di interruzione in un debugger.

Se stai usando Apache <2.3.9, dovrai usare [L]invece di [END]e tu potrebbe quindi essere necessario aggiungere:

RewriteRule ^show.php$ - [L]

Nella parte superiore del tuo set di regole, se l'URL /show.phpstesso viene riscritto.

Alcuni errori che ho osservato accadono durante la scrittura .htaccess

Utilizzo ^(.*)$ripetitivo di più regole, utilizzo^(.*)$ causa l'impotenza di altre regole nella maggior parte dei casi, poiché corrisponde a tutto l'URL in un singolo colpo.

Quindi, se stiamo usando la regola per questo url sapmle/url, consumerà anche questo url sapmle/url/string.

[L] flag dovrebbe essere usato per assicurarsi che la nostra regola abbia terminato l'elaborazione.

Dovrebbe sapere di:

Differenza in% n e $ n

%nviene abbinato durante la %{RewriteCond}parte e $ncorrisponde alla %{RewriteRule}parte.

Funzionamento di RewriteBase

La direttiva RewriteBase specifica il prefisso URL da utilizzare per le direttive RewriteRule per directory (htaccess) che sostituiscono un percorso relativo.

Questa direttiva è richiesta quando si utilizza un percorso relativo in una sostituzione in un contesto per directory (htaccess) a meno che non siano vere le seguenti condizioni:

La richiesta originale e la sostituzione sono sotto DocumentRoot (al contrario di raggiungibili con altri mezzi, come Alias). Il percorso del filesystem nella directory contenente RewriteRule, suffisso dalla relativa sostituzione è valido anche come percorso URL sul server (questo è raro). In Apache HTTP Server 2.4.16 e versioni successive, questa direttiva può essere omessa quando la richiesta viene mappata tramite Alias ​​o mod_userdir.

Se hai intenzione di scrivere più di una sola riga di regole in .htacesss,
non pensare nemmeno di provare uno di quei metodi hot-fix per eseguirne il debug.

Ho perso giorni a impostare più regole, senza feedback dai LOG, per poi rinunciare.
Ho avuto Apache sul mio PC, ho copiato l'intero sito sul suo HDD e ho risolto l'intero set di regole, usando i registri, molto velocemente.
Poi ho rivisto le mie vecchie regole, che funzionavano. Ho visto che non stavano davvero facendo ciò che era desiderato. Una bomba a orologeria, con un indirizzo leggermente diverso.

Ci sono così tante cadute nelle regole di riscrittura, non è affatto una cosa logica.
Puoi avere Apache attivo e funzionante in dieci minuti, è 10 MB, buona licenza, * NIX / WIN / MAC pronto, anche senza installazione.
Inoltre, controlla le righe di intestazione del tuo server e ottieni la stessa versione di Apache dal loro archivio se è vecchio. Il mio OP è ancora su 2.0; molte cose non sono supportate.

Lascio questo qui, forse un dettaglio ovvio, ma mi ha fatto battere la testa per ore: stai attento usando %{REQUEST_URI}perché ciò che @Krist van Besien dice nella sua risposta è assolutamente giusto, ma non per la stringa REQUEST_URI , perché l' output di questo TestString inizia con a /. Per cui riguardati:

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

(Simile all'idea di Doin) Per mostrare ciò che viene abbinato, io uso questo codice

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

Salvalo su r.php sul server root e poi fai alcuni test in .htaccess
Ad esempio, voglio abbinare gli URL che non iniziano con un prefisso linguistico

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

come sottolineato da @JCastell, il tester online fa un buon lavoro nel testare i reindirizzamenti individuali contro un file .htaccess. Tuttavia, più interessante è l' API esposto che può essere utilizzato per testare in batch un elenco di URL utilizzando un oggetto JSON. Tuttavia, per renderlo più utile, ho scritto un piccolo file di script bash che utilizza curl e jq per inviare un elenco di URL e analizzare la risposta json in un output formattato CSV con il numero di riga e la regola corrispondenti nel file htaccess insieme all'URL reindirizzato, rendendolo abbastanza utile confrontare un elenco di URL in un foglio di calcolo e determinare rapidamente quali regole non funzionano.

Se stai lavorando con url, potresti voler verificare se "Abilita riscrittura mod"