por que o .htaccess não redireciona solicitações no CentOS 7?

Question

Um aplicativo da Web em execução no CentOS 7 com o Apache 2.4 alterou recentemente seu nome de domínio de olddomain.com para newdomain.com . A estrutura do aplicativo no newdomain.com é diferente da do olddomain.com , portanto, todas as solicitações do olddomain.com/anyurl precisam ser redirecionadas para o URL raiz newdomain.com .

Um novo arquivo .htaccess foi criado e httpd foi reiniciado. Então, por que solicitações de olddomain.com/testbadurl não redirecionam para newdomain.com ? Em vez disso, o usuário recebe apenas um erro 404 erro em olddomain.com/testbadurl .

Aqui estão os passos que foram dados na linha de comando:

# nano /etc/httpd/conf/httpd.conf

    <Directory "/var/www/html">
        AllowOverride All
    </Directory>

# sudo systemctl restart httpd
# cd /var/www/html

# nano /var/www/html/.htaccess

    Options +FollowSymLinks
    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTP_HOST} !^olddomain\.com$ [NC]
    RewriteRule ^(.*)$ http://newdomain.com [R=301,L]

# systemctl restart httpd

Em seguida, o usuário de teste digita olddomain.com/testbadlink no navegador da web. Os logs em nano /var/log/httpd/olddomain_com_requests.log mostram um 404 error .

RESPOSTA:

@garethTheRed me fez pensar sobre VirtualHost diretivas nos arquivos httpd conf , o que me levou a desenvolver a seguinte resposta, que funciona e agora resolve o problema:

<VirtualHost www.olddomain.com:80>
    ServerName www.olddomain.com
    ServerAlias olddomain.com
    ErrorLog /var/log/httpd/olddomain_com_error.log
    CustomLog /var/log/httpd/olddomain_com_requests.log combined
    RedirectMatch ^(.*)$ http://newdomain.com
</VirtualHost>  

Observe que é mais seguro ter os arquivos httpd conf do que permitir acesso externo a um arquivo .htaccess .

    

Answer 1

Vou colocar minha cabeça acima do parapeito com essa resposta - afinal, uma resposta é deletável!

O Apache processa seus módulos em uma ordem não muito bem definida. Você pode visualizar a ordem de processamento ativando o módulo mod_info . Em uma instalação do Fedora 22, isso surgiu com o seguinte (extact):

Post-Read Request: 
   -10 mod_http2.c 
   00 mod_headers.c 
   00 mod_remoteip.c 
   00 mod_proxy.c 
   10 mod_auth_digest.c 
   10 mod_http2.c 
   10 mod_reqtimeout.c 
   10 mod_setenvif.c 
   10 mod_unique_id.c 
Header Parse: 
   10 mod_setenvif.c 
HTTP Scheme: 
   30 http_core.c 
Default Port: 
   30 http_core.c 
Quick Handler: 
   00 mod_cache.c 
   00 mod_lua.c 
Translate Name: 
   -1 mod_lua.c 
   00 mod_rewrite.c 
   00 mod_proxy.c 
   00 mod_proxy_express.c 
   10 mod_alias.c 
   10 mod_userdir.c 
   10 mod_vhost_alias.c 
   10 mod_lua.c 
   21 mod_lua.c 
   30 core.c 

Você notará que mod_proxy.c é o primeiro da lista.

Meu (muito limitado) entendimento é que suas configurações de proxy serão processadas primeiro, ponto no qual seus arquivos WAR são retornados e, portanto, a reescrita nunca é aplicada.

Existem maneiras de usar o proxy usando apenas mod_rewrite e o sinal [P] , conforme explicado na documentação do apache aqui . Pode ser útil neste cenário.

    

Answer 2

Você precisa ativar o módulo "reescrever" para obter o trabalho .hatccess:

a2enmod rewrite
service httpd restart