☰

Apache 2.4 Converta .htaccess e reescreva-o em vhost.conf

tag-icon • tag-icon apache-2.4 virtualhost .htaccess mod-rewrite
Apache 2.4 Converta .htaccess e reescreva-o em vhost.conf

Estou reescrevendo a configuração do Apache 2.4 que recebi da antiga equipe de desenvolvimento.

Tenho cerca de 200 linhas de configuração semelhante e não consigo entender em que princípio preciso alterar esse código para movê-lo para .htaccesso virtualhost.

RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_URI} !^/application-module/(.*)$
RewriteCond %{REQUEST_URI} !(.*)json$ [NC]
RewriteCond %{REQUEST_URI} !playground/local-loader/(.*)$ [NC]
RewriteRule ^(.*)$ /$1/ [R,L,NC]

Quando eu movo para o host virtual, meu site trava em lugares que não entendo.

Responder1

Depende de onde <VirtualHost>você está colocando essas diretivas no contêiner.

Se você estiver usando um <Directory>contêiner (ou seja, umdiretóriocontexto) edesabilitando .htaccesssubstitui completamente (caso contrário, .htaccesssubstituirá o <Directory>contêiner!), então você pode praticamente copiar as diretivas como estão (assumindo que o <Directory>contêiner faça referência ao mesmo diretório que o .htaccessarquivo).

No entanto, se você estiver colocando essas diretivas diretamente dentro do <VirtualHost>contêiner (fora de um <Directory>contêiner), ou seja. em umhost virtualcontexto, então você precisa fazer algumas alterações. Isso ocorre porque as diretivas são processadas anteriormente, antes de a solicitação ser mapeada para o sistema de arquivos.

Nas diretivas que você postou, apenas duas alterações seriam necessárias:

  • Em umhost virtualcontexto, a REQUEST_FILENAMEvariável do servidor ainda não foi resolvida para umnome do arquivo. É o mesmo que REQUEST_URI(ou seja, o URL solicitado). Portanto, a verificação do seu sistema de arquivos sempre falhará e a condição sempre será bem-sucedida! Você também precisa usar um lookahead. por exemplo. %{LA-U:REQUEST_FILENAME}ou construa você mesmo o nome de arquivo absoluto. por exemplo. %{DOCUMENT_ROOT}%{REQUEST_URI}. Por exemplo:

    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

  • Em umhost virtualcontexto, o caminho da URL que corresponde aoRewriteRule padrãoé relativo à raiz (começando com uma barra). Considerando .htaccessque é relativo ao diretório que contém o .htaccessarquivo - menos o prefixo da barra. Portanto, a regra escrita resultaria em uma barra dupla no início do caminho da URL; em vez disso, ela deveria ser reescrita assim:

    RewriteRule ^/(.*)$ /$1/ [R,L]

    (A NCbandeira não é necessária aqui.)

    Ou (preferível) não use uma referência anterior aqui e use a REQUEST_URIvariável do servidor (que naturalmente funcionaria .htaccesstambém). Por exemplo:

    RewriteRule ^ %{REQUEST_URI}/ [R,L]

    (Aparte:Provavelmente também deve ser um redirecionamento 301 permanente (ou seja, R=301). Da forma como está, o padrão será um redirecionamento temporário 302. Mas só mude para 301 - se essa for a intenção - depois de confirmar que funciona conforme o esperado.)

Então, em resumo, isso se tornaria:

RewriteCond %{QUERY_STRING} ^$
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_URI} !^/application-module/(.*)$
RewriteCond %{REQUEST_URI} !(.*)json$ [NC]
RewriteCond %{REQUEST_URI} !playground/local-loader/(.*)$ [NC]
RewriteRule ^/(.*)$ /$1/ [R,L]

Aparte:

O acima pode ser imediatamente otimizado movendo a verificação do sistema de arquivos (que é relativamentecaro) para a última condição e movendo odoençaque verifica se a solicitação ainda não termina com uma barra na RewriteRulediretiva. Além disso, os subpadrões regex (.*)em cada um doscondiçõesnão são necessários. Portanto, o acima poderia ser reescrito de forma mais eficiente:

RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_URI} !^/application-module/
RewriteCond %{REQUEST_URI} !json$ [NC]
RewriteCond %{REQUEST_URI} !playground/local-loader/ [NC]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule !/$ %{REQUEST_URI}/ [R,L]

A verificação do sistema de arquivos talvez possa ser completamente removida se você excluir solicitações que contenham (o que parece ser) uma extensão de arquivo, mas isso pode depender da estrutura do seu arquivo.

Odoençaessa verificação !json$parece que realmente deveria estar verificando a .jsonextensão do arquivo, ou seja. !\.json$. (Isso está de acordo com meu comentário acima sobre a exclusãotodossolicitações que possuem uma "extensão de arquivo".)

O primeirodoençaque verifica se a string de consulta está vazia parece um pouco estranho (já que realmente não importa se existe uma string de consulta ou não ao anexar uma barra ao caminho da URL), mas presumo que este deva ser um requisito específico.

informação relacionada