Muitos pôsteres têm problemas ao depurar suas instruções RewriteRule e RewriteCond em seus .htaccessarquivos. A maioria deles está usando um serviço de hospedagem compartilhada e, portanto, não tem acesso à configuração do servidor raiz. Eles não podem evitar o uso de .htaccessarquivos para reescrever e não podem ativar um RewriteLogLevel ", como sugerem muitos entrevistados. Além disso, existem muitas .htaccessarmadilhas e restrições específicas que não são bem cobertas. A configuração de uma pilha LAMP de teste local envolve muita curva de aprendizado para a maioria dos usuários. .

Portanto, meu Q aqui é como recomendamos que eles próprios depurem suas regras . Eu forneço algumas sugestões abaixo. Outras sugestões seriam apreciadas.

1. Entenda que o mecanismo mod_rewrite alterna entre .htaccessarquivos . O mecanismo executa este loop:

   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
   

   Portanto, suas regras serão executadas repetidamente e, se você alterar o caminho do URI, poderá acabar executando outros .htaccessarquivos, se existirem. Portanto, certifique-se de encerrar esse loop, se necessário, adicionando extra RewriteCondpara interromper o disparo das regras. Exclua também quaisquer .htaccessconjuntos de regras de reescrita de nível inferior, a menos que haja intenção explícita de usar conjuntos de regras de vários níveis.

2. Certifique-se de que a sintaxe de cada Regexp esteja correta testando contra um conjunto de padrões de teste para garantir que seja uma sintaxe válida e faça o que você pretende com uma gama completa de URIs de teste. Veja a resposta abaixo para mais detalhes.

3. Construa suas regras incrementalmente em um diretório de teste. Você pode usar o .htaccessrecurso "executar o arquivo mais profundo no caminho" para configurar um diretório de teste separado (árvore) e depurar conjuntos de regras aqui sem estragar suas regras principais e interromper o funcionamento do site. Você deve adicioná-los um de cada vez, porque esta é a única maneira de localizar falhas em regras individuais.

4. Use um stub de script fictício para despejar variáveis ​​de servidor e ambiente . (Consulte a Listagem 2 ) Se seu aplicativo usar, digamos, blog/index.phpvocê poderá copiá-lo test/blog/index.phpe usá-lo para testar as regras do seu blog no testsubdiretório. Você também pode usar variáveis ​​de ambiente para garantir que o mecanismo de reescrita na interpretação correta das cadeias de substituição, por exemplo,

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

   e procure essas variáveis REDIRECT_ * no dump do phpinfo. BTW, eu usei este e descobri no meu site que eu tinha que usar em seu %{ENV:DOCUMENT_ROOT_REAL}lugar. No caso do redirecionador executar um loop, as variáveis REDIRECT_REDIRECT_ * listam a passagem anterior. Etc.

5. Certifique-se de que você não seja mordido pelo navegador fazendo o cache de redirecionamentos 301 incorretos . Veja a resposta abaixo . Meus agradecimentos a Ulrich Palha por isso.

6. O mecanismo de reescrita parece sensível às regras em cascata dentro de um .htaccesscontexto (é aí que RewriteRuleresulta em uma substituição e isso cai para outras regras), pois encontrei bugs com sub-solicitações internas (1) e processamento PATH_INFO incorreto que geralmente pode evita o uso dos sinalizadores [NS], [L] e [PT].

Mais algum comentário ou sugestão?

Listagem 1 - phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

Aqui estão algumas dicas adicionais sobre regras de teste que podem facilitar a depuração para usuários em hospedagem compartilhada

1. Use um agente de usuário falso

Ao testar uma nova regra, adicione uma condição para executá-la apenas com um fakeuser agent que você usará para suas solicitações. Dessa forma, não afetará mais ninguém em seu site.

por exemplo

#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 você estiver usando o Firefox, poderá usar o User Agent Switcher para criar a cadeia e o teste falsos do agente do usuário.

2. Não use 301 até concluir o teste

Eu já vi muitos posts em que as pessoas ainda estão testando suas regras e usando 301. NÃO .

Se você não estiver usando a sugestão 1 no seu site, não apenas você, mas qualquer pessoa que visite o site no momento será afetada pelo 301.

Lembre-se de que eles são permanentes e agressivamente armazenados em cache pelo seu navegador. Use um 302 até ter certeza e altere-o para um 301.

3. Lembre-se de que os 301 são armazenados em cache agressivamente no seu navegador

Se sua regra não funcionar e parecer correta para você, e você não estiver usando as sugestões 1 e 2, faça um novo teste depois de limpar o cache do navegador ou durante a navegação privada.

4. Use uma ferramenta de captura de HTTP

Use uma ferramenta de captura de HTTP como o Fiddler para ver o tráfego HTTP real entre o navegador e o servidor.

Enquanto outros podem dizer que site does not look rightvocê é, você pode ver e relatar isso all of the images, css and js are returning 404 errors, diminuindo rapidamente o problema.

Enquanto outras pessoas reportarem que você started at URL A and ended at URL C, você poderá ver que elas começaram em URL A, were 302 redirected to URL B and 301 redirected to URL C. Mesmo que o URL C seja o objetivo final, você saberá que isso é ruim para o SEO e precisa ser corrigido.

Você poderá ver os cabeçalhos de cache definidos no servidor, reproduzir solicitações novamente, modificar cabeçalhos de solicitação para testar ....

Teste de reescrita on-line .htaccess

Encontrei essa ajuda do Googling for RegEx, que me salvou muito tempo de ter que fazer upload de novos .htaccessarquivos toda vez que faço uma pequena modificação.

do site:

testador de htaccess

Para testar suas regras de reescrita do htaccess, basta preencher o URL ao qual você está aplicando as regras, colocar o conteúdo do htaccess na área de entrada maior e pressionar o botão "Verificar agora".

Não se esqueça que nos arquivos .htaccess é um URL relativo correspondente.

Em um arquivo .htaccess, o seguinte RewriteRule nunca corresponderá:

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

Verifique se a sintaxe de cada Regexp está correta

testando contra um conjunto de padrões de teste para garantir que seja uma sintaxe válida e faça o que você pretende com uma gama completa de URIs de teste.

Veja regexpCheck.php abaixo para obter um script simples que você pode adicionar a um diretório privado / teste em seu site para ajudá-lo a fazer isso. Eu mantive isso breve e não bonito. Basta colar isso em um arquivo regexpCheck.phpem um diretório de teste para usá-lo em seu site. Isso o ajudará a criar qualquer regexp e testá-lo em uma lista de casos de teste ao fazê-lo. Estou usando o mecanismo PHP PCRE aqui, mas, tendo examinado a fonte do Apache, isso é basicamente idêntico ao usado no Apache. Existem muitos HowTos e tutoriais que fornecem modelos e podem ajudá-lo a desenvolver suas habilidades em regexp.

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

Certifique-se de usar o sinal de porcentagem na frente das variáveis, não o sinal de cifrão.

É %{HTTP_HOST}, não ${HTTP_HOST} . Não haverá nada no error_log, não haverá erros internos do servidor, seu regexp ainda está correto, a regra simplesmente não coincide. Isso é realmente hediondo se você trabalha muito com modelos de django / genshi e tem ${}uma substituição variável na memória muscular.

Uma de algumas horas que eu perdi:

Se você aplicou todas essas dicas e está executando apenas 500 erros porque não tem acesso ao log de erros do servidor, talvez o problema não esteja no .htaccess, mas nos arquivos para os quais ele redireciona.

Depois de corrigir meu problema .htaccess, passei mais duas horas tentando corrigi-lo um pouco mais, apesar de simplesmente ter esquecido algumas permissões.

Defina variáveis ​​de ambiente e use cabeçalhos para recebê-las:

Você pode criar novas variáveis ​​de ambiente com as linhas RewriteRule, conforme mencionado pelo OP:

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

Mas se você não consegue que um script do lado do servidor funcione, como você pode ler essa variável de ambiente? Uma solução é definir um cabeçalho:

Header set TEST_FOOBAR "%{REDIRECT_TEST0}e"

O valor aceita especificadores de formato , incluindo o %{NAME}eespecificador para variáveis ​​de ambiente (não esqueça o e minúsculo). Às vezes, você precisará adicionar o REDIRECT_prefixo, mas não resolvi quando o prefixo foi adicionado e quando não.

Se você estiver criando redirecionamentos, teste com curl para evitar problemas de cache do navegador. Use -I para buscar apenas cabeçalhos http. Use -L para seguir todos os redirecionamentos.

Encontrei essa pergunta ao tentar depurar meus problemas com o mod_rewrite e, definitivamente, temos alguns conselhos úteis. Mas no final, o mais importante é garantir que a sintaxe do regex esteja correta. Devido a problemas com a minha própria sintaxe RE, a instalação do script regexpCheck.php não era uma opção viável.

Mas como o Apache usa Expressões Regulares Compatíveis com Perl (PCRE), qualquer ferramenta que ajude a escrever PCREs deve ajudar. Eu usei a ferramenta do RegexPlanet com Java e Javascript REs no passado e fiquei feliz ao descobrir que eles também suportam Perl.

Basta digitar sua expressão regular e um ou mais URLs de exemplo, e ele informará se a regex corresponde (um "1" na coluna "~ =") e, se aplicável, quaisquer grupos correspondentes (os números na "divisão" A coluna corresponderá aos números que o Apache espera, por exemplo, $ 1, $ 2 etc.) para cada URL. Eles alegam que o suporte ao PCRE está "na versão beta", mas era exatamente o que eu precisava para resolver meus problemas de sintaxe.

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

Eu simplesmente adicionaria um comentário a uma resposta existente, mas minha reputação ainda não está nesse nível. Espero que isso ajude alguém.

Em relação à 4., você ainda precisa garantir que o seu "stub de script fictício" seja realmente o URL de destino após toda a reescrita, ou você não verá nada!

Um truque semelhante / relacionado (consulte esta pergunta ) é inserir uma regra temporária como:

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

Onde show.phpestá um script muito simples que apenas exibe seus $_GETparâmetros (você também pode exibir variáveis ​​de ambiente, se desejar).

Isso interromperá a reescrita no ponto em que você a insere no conjunto de regras, como um ponto de interrupção em um depurador.

Se você estiver usando o Apache <2.3.9, precisará usar em [L]vez de [END]e poderá adicionar:

RewriteRule ^show.php$ - [L]

No topo do seu conjunto de regras, se o /show.phppróprio URL estiver sendo reescrito.

Alguns erros que observei acontecem ao escrever .htaccess

O uso ^(.*)$repetitivo de várias regras, o uso ^(.*)$faz com que outras regras sejam impotentes na maioria dos casos, porque corresponde a todo o URL em um único hit.

Portanto, se estivermos usando a regra para esse URL, sapmle/urlele também consumirá esse URL sapmle/url/string.

[L] O sinalizador deve ser usado para garantir que nossa regra tenha processado.

Deve saber sobre:

Diferença em% ne $ n

%né correspondido durante %{RewriteCond}parte e $ncorresponde a %{RewriteRule}parte.

Trabalho de RewriteBase

A diretiva RewriteBase especifica o prefixo da URL a ser usado para as diretivas RewriteRule por diretório (htaccess) que substituem um caminho relativo.

Essa diretiva é necessária quando você usa um caminho relativo em uma substituição no contexto por diretório (htaccess), a menos que qualquer uma das seguintes condições seja verdadeira:

A solicitação original e a substituição estão embaixo do DocumentRoot (em vez de alcançáveis ​​por outros meios, como o Alias). O caminho do sistema de arquivos para o diretório que contém o RewriteRule, com o sufixo da substituição relativa, também é válido como um caminho de URL no servidor (isso é raro). No Apache HTTP Server 2.4.16 e posterior, essa diretiva pode ser omitida quando a solicitação é mapeada via Alias ​​ou mod_userdir.

Se você planeja escrever mais do que apenas uma linha de regras em .htacesss,
nem pense em tentar um desses métodos de hot-fix para depurá-lo.

Eu perdi dias definindo várias regras, sem o feedback dos LOGs, apenas para finalmente desistir.
Coloquei o Apache no meu PC, copiei o site inteiro para o disco rígido e classifiquei todo o conjunto de regras, usando os logs, muito rápido.
Depois revi minhas regras antigas, que estavam funcionando. Vi que eles não estavam realmente fazendo o que era desejado. Uma bomba-relógio, com um endereço um pouco diferente.

Existem tantas quedas nas regras de reescrita, que não é absolutamente uma coisa lógica.
Você pode instalar o Apache em dez minutos, com 10 MB, boa licença, * NIX / WIN / MAC pronto, mesmo sem instalação.
Além disso, verifique as linhas de cabeçalho do seu servidor e obtenha a mesma versão do Apache em seus arquivos, se ela for antiga. Meu OP ainda está no 2.0; muitas coisas não são suportadas.

Vou deixar isso aqui, talvez detalhes óbvios, mas fiquei com a cabeça por horas: tome cuidado, %{REQUEST_URI}porque o que @Krist van Besien diz em sua resposta é totalmente correto, mas não para a sequência REQUEST_URI , porque a saída disso TestString começa com um /. Então tome cuidado:

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

(Semelhante à idéia de Doin) Para mostrar o que está sendo correspondido, eu uso esse código

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

Salve-o em r.php na raiz do servidor e faça alguns testes em .htaccess
Por exemplo, eu quero corresponder URLs que não iniciam com um prefixo de idioma

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

como apontado por @JCastell, o testador on - line faz um bom trabalho testando redirecionamentos individuais em um arquivo .htaccess. No entanto, mais interessante é a API exposta, que pode ser usada para testar em lote uma lista de URLs usando um objeto json. No entanto, para torná-lo mais útil, escrevi um pequeno arquivo de script bash que utiliza curl e jq para enviar uma lista de URLs e analisar a resposta json em uma saída formatada em CSV com o número da linha e a regra correspondentes no arquivo htaccess junto com o URL redirecionado, facilitando a comparação de uma lista de URLs em uma planilha e determinando rapidamente quais regras não estão funcionando.

Se você estiver trabalhando com o URL, convém verificar se "Habilitar a reconfiguração do mod"