mod_rewrite misteriosamente anexa subpasta ao url reescrito

Question

EDIT: [Resolvido] Finalmente encontrei a solução na documentação; postou uma resposta. Resumindo: o DPI flag.

EDIT: na parte inferior, adicionou uma maneira fácil de reproduzir o problema on-line.

Eu passei algumas horas debugando algumas reescritas. Tudo está bem, exceto um comportamento que me incomoda.

De alguma forma, quando alimentado com um url com dois ou mais subdiretórios, o mod_rewrite automaticamente anexa todos os subdiretórios (exceto o primeiro) ao url reescrito. Aqui está o exemplo mais simples que eu poderia reduzi-lo. Isso está em um htaccess em DOCUMENT_ROOT .

• url: http://localhost/stripthis/stripthat
• RewriteRule ^ RewriteWasHere_
• Saída: RewriteWasHere_/stripthat

De onde veio esse stripthat ? Alguma opção upstream poderia estar causando isso?

Eu tentei remover as subpastas com várias regras. Por exemplo:

• url: http://localhost/stripthis/stripthat
• RewriteRule ^/?([^/]+) RewriteWasHere_$1
• Saída: RewriteWasHere_stripthis/stripthat

Estranhamente, isso acontece tanto em um xampp x Apache 2.4.7 local quanto em um CentOS x Apache 2.2 remoto.

Eu inspecionei os URLs reescritos enviando-os para um script, mas aqui está uma maneira de reproduzir o problema on-line.

Como reproduzir este site

• Acesse este on-line testador de htaccess
• Para o URL, insira http://example.com/a/123/b

Para as regras, cole isto:

# the '(?!)' negative lookaheads are just to make triple sure
# we're not running the same rules multiple times
RewriteRule ^(?!m[yo])([^/]+) my_$1
#RewriteRule ^(?!mo])\D*(\d+) mo_$1:$1:$1

1. Executar: a saída é http://example.com/my_a/123/b
2. Descomente a segunda linha.
3. Executar: a saída é http://example.com/mo_123:123:123/b
4. Comente a segunda linha, altere a primeira linha para RewriteRule ^(?!m[yo])([^/]+).*$ my_$1 : o problema desaparece neste site, mas não nos meus servidores.

Qualquer ideia seria muito apreciada.

    

Answer 1

[DPI] (discardpathinfo)

Depois de horas de testes e perplexidade, voltei para a documentação e encontrei a solução : o sinalizador [DPI] .

The DPI flag causes the PATH_INFO portion of the rewritten URI to be discarded.

This flag is available in version 2.2.12 and later.

In per-directory context, the URI each RewriteRule compares against is the concatenation of the current values of the URI and PATH_INFO.

The current URI can be the initial URI as requested by the client, the result of a previous round of mod_rewrite processing, or the result of a prior rule in the current round of mod_rewrite processing.

In contrast, the PATH_INFO that is appended to the URI before each rule reflects only the value of PATH_INFO before this round of mod_rewrite processing. As a consequence, if large portions of the URI are matched and copied into a substitution in multiple RewriteRule directives, without regard for which parts of the URI came from the current PATH_INFO, the final URI may have multiple copies of PATH_INFO appended to it.

Use this flag on any substitution where the PATH_INFO that resulted from the previous mapping of this request to the filesystem is not of interest. This flag permanently forgets the PATH_INFO established before this round of mod_rewrite processing began. PATH_INFO will not be recalculated until the current round of mod_rewrite processing completes. Subsequent rules during this round of processing will see only the direct result of substitutions, without any PATH_INFO appended.

    

Answer 2

Talvez você esteja perdendo o $ na expressão RewriteRule , portanto, o material não é totalmente correspondido?

Você pode querer considerar a mudança para o nginx; tem uma documentação muito clara e razoável, sem o inchaço e o não-determinismo pelo qual o Apache é bastante famoso.