Suggerimenti per il debug delle regole di riscrittura di .htaccess


272

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);

10
Questi sono buoni ... Forse dovresti spostarli dalla domanda in una risposta.
wt

@ w00t, ho diviso il controllo regexp secondo il tuo suggerimento perché voglio fare riferimento tramite link in altre risposte.
TerryE,

3
Potresti voler aggiungere il diagramma di flusso di controllo dai documenti al tuo primo suggerimento. L'IMO è molto più facile da comprendere rispetto a qualsiasi pseudocodice o spiegazione, e questa è davvero la parte più nera del voodoo di riscrittura mod.
Sab

Il numero 6 è un grosso problema. Riscrivere le regole comportandosi diversamente nei file di configurazione standard di Apache rispetto ai file .htaccess deve catturare molte persone.
Iain Collins,

Qualcosa che potrebbe valere la pena aggiungere a questi suggerimenti: ho passato un po 'di tempo a debug di un problema con il reindirizzamento e non la riscrittura. Si scopre che l'ho fatto riscrivere in "/ comment" quando volevo "/ comment /". Stava riscrivendo in "/ comment" e quindi il server stava eseguendo un reindirizzamento a "/ comment /". Comportamento ovvio a quelli abituati ad Apache, ma probabilmente meno per i rumori come me.
Chris,

Risposte:


132

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



9
Ulrich, grazie mille per questo contributo. Hai raccolto alcuni aspetti che non avevo pensato di inserire nella mia lista. Sul problema del debug 301, utilizzo Chrome in "Navigazione privata" (AKA "Modalità pornografia") in quanto scarica queste informazioni sullo stato quando chiudi la finestra. Spero che non ti dispiaccia che io non "accetti" questo dato che è un punto importante, ma non una sola risposta migliore. Grazie ancora. :)
TerryE

1
Per chiarire (ce l'hai nel tuo codice ma non lo hai individuato) ma per assicurarti di utilizzare un reindirizzamento 302 non 301 è necessario[L,R=302]
icc97,

6
Non è necessario specificare esplicitamente, [L, R=302]basta fare che [L,R]l'impostazione predefinita sia302
Rahil Wazir,

2
@goodeye, guarda anche la casella di controllo "Chrome> Impostazioni> Generale> Disabilita cache mentre DevTools è aperto".
johnsnails

83

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".


6
Grazie per il puntatore a questo strumento, che ho trovato il modo più diretto per eseguire il debug del mio problema.
Bob

Se hai accesso ssh al tuo spazio web, un'altra opzione è quella di modificare .htaccess direttamente tramite l'editor sul server.
sjas,

Dovrai ignorare l'avvertimento ssl in caso di problemi con il certificato del sito. Ma il sito è ancora lì. Questa è la soluzione migliore e più semplice. Fornisce una visione incredibile di ciò che è sbagliato e si risolve rapidamente.
toddmo,

Grazie per aver indicato questo strumento. È utile, a volte il debug dell'apache stesso è estremamente difficile. Grazie. Grazie
mille

Sembra che il link a cui si fa riferimento sia errato e non fornisca sempre l'output esatto. Si prega di verificare l'apache reale per essere assolutamente sicuri.
Part

13

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

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

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

4
Sì, la stringa inserita in una Regola di riscrittura è relativa e quindi viene rimossa da qualsiasi inizio /, ma questo stripping non si verifica per le stringhe di corrispondenza assemblate nei comandi Rewrite Cond .
TerryE

8

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>

1
Nota rapida: è import_request_variablesstato deprecato in PHP 5.3 e rimosso in 5.4. extract($_GET)accoppiato con extract($_POST)può svolgere la stessa funzione, ma tutte le variabili avrebbero bisogno del prefisso rimosso dal loro nome. Fonte: php.net/manual/en/function.import-request-variables.php
Jeff Lambert,

@watcher, grazie. Avevo aggiornato la mia versione locale in modo che fosse 5.4 compatibile un anno fa, ma ho dimenticato di modificare questo post. Ora fatto.
TerryE

oh mio Dio, anche dopo la modifica, non posso ottenere buoni risultati semplicemente copiando il tuo codice ... ma con i violinisti di regex in giro, credo che il tuo strumento sia comunque obsoleto. dai un'occhiata a questi fantastici strumenti: regex101.com o refiddle.com o regexr.com
hexerei software

@hexereisoftware, questo post ha 3 anni, quindi potrebbero esserci problemi sottili a seconda della versione di PHP che ora utilizza e della versione di Apache. Tuttavia ci sono molte varianti di regexp ognuna con sottili differenze. Come ho detto, il codice Apache utilizza un motore PCRE che è molto simile al motore PHP. Non sono sicuro di quali siano le differenze con le altre varianti come .Net, quindi mentre il tuo suggerimento di utilizzare una risorsa online è buono, rimarrei con uno che supporta esplicitamente la sintassi di apache o PHP. :-)
TerryE

Perl non sarebbe il più vicino, ma php usa la stessa sintassi
hexerei software

7

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.


1
Sì, le variabili di sostituzione $ si riferiscono all'ultimo modello RewriteRule e quelle % si riferiscono all'ultimo modello RewriteCond e speciali come% {env: XXX}
TerryE

7

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.


Uso un servizio web di hosting ad accesso condiviso per il mio sito personale, ma quello che ho fatto è impostare una VM di prova che rispecchi all'incirca questo in termini di configurazione PHP / Apache, home directory, ecc. Tuttavia perché questa VM sotto il mio admin Posso abilitare la riscrittura della registrazione per diagnosticare eventuali .htaccessproblemi difficili .
TerryE

6

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.


Hai acquisito ulteriori informazioni su quando utilizzare o non utilizzare il REDIRECT_prefisso? Inoltre, vedo la terminologia relativa ai prefissi anche in altri contesti (htaccess), ma non è mai stato chiaro esattamente cosa si intende. Significa che devi nominare la tua variabile con il prefisso, o aggiungere il prefisso alla tua variabile nominata, quando usi determinati comandi (ma non altri comandi)? Il tuo esempio è il primo che mostra sia la definizione var, sia l'utilizzo var, quindi da questo sono propenso a pensare a quest'ultimo! I documenti sono stati di scarso aiuto, presumono che ne sappiamo troppo e forniscono troppi riferimenti / collegamenti.
SherylHohman,

5

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.


3

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.


strumento carino, ma forma terribile ... dai un'occhiata a questi fantastici strumenti: regex101.com o refiddle.com o regexr.com
hexerei software

3

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.


3

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.


2

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.


papo, ho gestito server dedicati, VPS ospitati da ISP e VM private all'interno della mia struttura di sviluppo, ma utilizzo ancora un servizio di hosting condiviso per i miei domini pubblici e la mia e-mail, semplicemente perché è più conveniente ed economico utilizzare un sistema completamente gestito servizio per questi. Questo howto è davvero rivolto agli utenti dei servizi condivisi. Configurare una VM privata per il mirroring completo di un servizio condiviso è difficile. Sì, se è possibile utilizzare una macchina virtuale di prova aiuta, ma di tanto in tanto utilizzo questi "trucchi" sul mio servizio condiviso.
TerryE

1
Sarei d'accordo con questo se la tua A fosse stata inquadrata come un suggerimento alternativo per le mod_rewriteregole di debug , ma l'apertura "non pensarci nemmeno" è semplicemente un cattivo consiglio per gli utenti di servizi condivisi di base che fanno fatica a capire perché i loro htaccessfile non sono ' t nel modo in cui fanno ciò che dovrebbero.
TerryE

Mi dispiace se sembrava che il tuo lavoro di mettere insieme una bella raccolta di consigli fosse inutile. Non volevo quello. Credetemi, sono stato molto felice di leggere e seguire molti consigli offerti da questa discussione. Ma le mie regole sono diventate lentamente complicate e alla fine ho perso molto tempo non volendo passare attraverso il problema di installare un server Apache e fare il debug come dovrebbe essere fatto. Oltre a ciò, non ho imparato nulla, come non ho visto, nei registri, cosa stava realmente accadendo. E ci sono molte cose in corso. Credo che sia anche prezioso condividere questa esperienza.
papo,

per la seconda parte, esiste un IF. Il mio testo non è mai iniziato con 'non pensare nemmeno', vedo ora, questa formulazione sembra un po 'dura ma è tutto vero. Soprattutto per coloro che sono nuovi a questo e che lottano per capire. Consiglia qui potrebbe sbagliare, come me, che tutto ciò di cui ho bisogno è una solida regex, non è così semplice, come il tuo punto 6) PATH_INFO mi è costato un sacco di problemi e non è un bug come dici tu, ma una caratteristica. Se non si desidera che venga nuovamente aggiunto, utilizzare [DPI]. Ma solo se guarderai i log, vedrai che è stato aggiunto lì. Ecco perché, più di una riga, e stai meglio usando i registri
papo,

1
Mi dispiace @papo, ma la mia ragione per il voto -1 è stata che penso che questo "non ci pensi nemmeno" è un cattivo consiglio, IMO. Se il tuo punto era che "al di sopra di una certa complessità, potresti trovare più facile installare un servizio Apache locale per il debug dei tuoi .htaccessfile", allora questo è più bilanciato. Sì, è ragionevolmente facile impostare un servizio Apache locale, ma ottenerlo per riflettere il servizio di hosting condiviso di un fornitore di servizi può essere complicato e oltre il livello di abilità di molti utenti che potrebbero aver appena utilizzato una configurazione di Wordpress con un clic, dire, e hanno problemi con il loro .htaccessfile.
TerryE

1

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

0

(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

1
usare semplicemente uno stub phpinfo () come ho detto al punto 4 sul mio O / P fa sostanzialmente la stessa cosa. CercaQUERY_STRING
TerryE,

0

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.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.