Início / server / Perguntas / 1165053
Accepted
TRiG
Asked: 2024-09-10 21:36:22 +0800 CST

Na configuração do Apache, os redirecionamentos ou as regras de reescrita têm precedência?

  • 772

Quero que um domínio no Apache exista puramente como um redirecionamento. Para esse fim, crio /etc/apache2/sites-available/redirect.example.info.confo seguinte:

<VirtualHost *:80>
    ServerName redirect.example.info
    ServerAdmin webmaster@localhost
    Redirect / https://example.com/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Quando executo certbot --apache, isso é reescrito para:

<VirtualHost *:80>
    ServerName redirect.example.info
    ServerAdmin webmaster@localhost
    Redirect / https://example.com/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

RewriteEngine on
RewriteCond %{SERVER_NAME} =redirect.example.info
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

E um novo arquivo /etc/apache2/sites-available/redirect.example.info-le-ssl.confé criado:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName redirect.example.info
    ServerAdmin webmaster@localhost
    Redirect / https://example.com/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLCertificateFile /etc/letsencrypt/live/ca-webs.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ca-webs.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Isso funciona como desejado. Os redirecionamentos são executados http://redirect.example.info→ https://redirect.example.info→ https://example.com. Mas não é óbvio para mim como está funcionando. O arquivo reescrito tem um Redirectcomando e um RewriteRulecomando, e eu pensei que o Redirect(vindo primeiro) teria precedência. Como esse arquivo é realmente avaliado?

apache2

1 respostas

  1. Best Answer

    AFAIK certbot --apachenão faz um exame rigoroso do HTTP VirtualHost existente, ele simplesmente copia todas as diretivas existentes e adiciona diretivas TLS para gerar um novo HTTPS VirtualHost.
    O HTTP VirtualHost simples é então modificado para incluir um redirecionamento condicional HTTP --> HTTPS (para redirecionar apenas URIs para os quais o certbot configurou um certificado).

    A configuração resultante é adequada para a maioria dos casos de uso, mas no seu caso o resultado é subótimo e eu sugeriria que você editasse manualmente o HTTP Virtual Host simples. Remova as Rewrite*diretivas que o certbot adicionou e reverta para sua configuração original que envia visitantes diretamente de http://redirect.example.info para https://example.compara evitar aquela visita intermediária redundante para https://redirect.example.info.

    Quanto ao motivo pelo qual as Rewrite*diretivas têm precedência, embora apareçam depois da Redirectdiretiva: isso ocorre porque a configuração efetiva do httpd do Apache não é somente o resultado de onde, em qual ordem e em qual contêiner as diretivas de configuração são colocadas e agrupadas, mas também depende de qual(is) módulo(s) as diretivas pertencem.

    Essa informação não é imediatamente óbvia na seção "mesclagem" do manual https://httpd.apache.org/docs/current/sections.html#merging

    Relação entre módulos e seções de configuração

    Uma questão que frequentemente surge após ler como as seções de configuração são mescladas está relacionada a como e quando as diretivas de módulos específicos como mod_rewrite são processadas. A resposta não é trivial e precisa de um pouco de contexto. Cada módulo httpd gerencia sua própria configuração, e cada uma de suas diretivas especifica httpd.confuma parte da configuração em um contexto particular. O httpd não executa um comando enquanto ele é lido.

    No tempo de execução, o núcleo do httpd itera sobre as seções de configuração definidas na ordem descrita acima para determinar quais se aplicam à solicitação atual. Quando a primeira seção corresponde, ela é considerada a configuração atual para esta solicitação. Se uma seção subsequente também corresponder, cada módulo com uma diretiva em qualquer uma das seções tem a chance de mesclar sua configuração entre as duas seções. O resultado é uma terceira configuração, e o processo continua até que todas as seções de configuração sejam avaliadas.

    Após a etapa acima, o processamento "real" da solicitação HTTP começa: cada módulo tem a chance de executar e realizar quaisquer tarefas que desejar. Eles podem recuperar sua própria configuração final mesclada do núcleo do httpd para determinar como devem agir.

    Para mod_rewrite o detalhe sutil provavelmente está na frase "cada módulo tem uma chance de executar e realizar quaisquer tarefas que eles gostem" .
    Os módulos podem/devem se registrar por meio de ganchos de processamento de solicitação para serem capazes de "fazer o que eles gostam" no momento certo e mod_rewrite usa isso para vir primeiro (ou pelo menos mais cedo) com o APR_HOOK_FIRSTgancho https://github.com/apache/httpd/blob/c72b74ccef72fb56becd55888a3aa783c4ab5b6b/modules/mappers/mod_rewrite.c#L5702

    Até onde eu sei, é assim que Rewrite*as diretivas ganham precedência sobre as outras, independentemente de como/onde essas outras diretivas são ordenadas.

    Você pode obter insights sobre os ganchos e todos os módulos habilitados e sua ordenação habilitando mod_info (não se esqueça de adicionar ACLs à URL server-info).

    • 0

relate perguntas