Uma ou mais declarações da diretiva RewriteCond podem ser utilizadas para restringir (impor condições prévias) sobre quais requisições estão sujeitas a avaliação por uma RewriteRule.

Neste caso, para cada condição avaliada a URL é testada para verificar se atende a um requisito prévio. Se todas as condições estiverem satisfeitas (verdadeiras), então a URL é finalmente avaliada por uma diretiva RewriteRule em uma avaliação final que faz a reescrita. Observe a sintaxe de RewriteCond: O primeiro argumento (TestString) tipicamente é uma variável de ambiente que pode vir de várias fontes e formatos. O mais comum são variáveis que descrevem uma característica vinda da requisição (HTTP HEADER), com origem no próprio servidor (Server Internals), da conexão, de padrões de data e hora ou outras origens especiais (mais complexas e não citadas neste artigo). TestString também pode conter variáveis que vem de referências internas de diretivas RewriteRule ($N) ou de outras diretivas RewriteCond (%N). Os valores de N em ambos os casos vem da delimitação com parêntesis nessas diretivas. Existe a origem em RewriteMap que não veremos nesse material.

Cada um dos tipos especiais possui sua própria sintaxe, que não veremos nesse material.

O segundo argumento (Condition) pode assumir três funções:

1. Uma regex;
2. Uma cadeia de texto para comparação (string);
3. Um teste para um diretório ou arquivo no filesystem.

1. Uma regex que deve combinar com o valor da variável em TestString.

2. Uma comparação lexicográfica entre o valor de TestString e o valor em Condition fará a comparação entre as cadeias de caracteres como um dicionário onde Carla vem antes de Carta. Ou como Dinheiro que vem antes de Esforço apenas no dicionário. As opções de comparação são:

• "<CondPattern" - é verdadeiro se precede TestString.
• ">CondPattern" - é verdadeiro se sucede TestString.
• "=CondPattern" - é verdadeiro se é equivalente (letra a letra) a TestString.

3. O teste para o sistema de arquivos verifica se:

• -d - Trata o conteúdo de TestString como um pathname e testa se existe ou não e se é um diretório;
• -f - Trata o conteúdo de TestString como um pathname e testa se existe ou não e se é um arquivo regular;
• -s - Trata o conteúdo de TestString como um pathname e testa se existe ou não e se é um arquivo regular cujo conteúdo é maior que zero;
• -l - Trata o conteúdo de TestString como um pathname e testa se existe ou não e se é uma ligação simbólica;
• -x - Trata o conteúdo de TestString como um pathname e testa se existe ou não e se é um arquivo com permissões de execução.

Todos esses casos podem ser prefixados com o sinal de exclamação (!) para negar (inverter) seu significado.

O terceiro argumento de RewriteCond é opcional. Eles podem aparecer sozinhos ou juntos em uma lista de sinalizadores separados por vírgula.

[NC] - No Case indica que o teste é case insensitive. Não tem efeito sobre comparações no sistema de arquivos, sendo efetiva entre a comparação de TestString e CondPattern.

[OR] - O sinal OR representa um OU Lógico. A inversão de um OU Lógico por negação é um AND lógico.

Por exemplo, para enviar todas as requisições de uma faixa de IP's para um servidor diferente, a seguinte regra pode ser utilizada:


Quando mais de uma RewriteCond é definida, então TODAS elas devem ser combinadas (satisfeitas) para que a regra em RewriteRule seja aplicada. Por exemplo, para negar acesso a requisições que tenham a palavra "hack" na cadeia de consulta (query_string), a menos que exista um cookie com a palavra "go", as seguintes regras são utilizadas:


A exclamação em !go significa que no cookie não pode haver a palavra go. Combinadas as expressões regulares das duas RewriteCond o valor de Substitution contido na diretiva RewriteRule será utilizado. Neste exemplo o sinalizador [F] nega acesso (Forbidden).

No caso onde o sinalizador [OR] é utilizado, basta uma das condições verdadeiras para aplicar a regra: