.htaccess ignorado, ESPECÍFICO para EC2 - não os suspeitos usuais

Question

Eu executo 8-10 servidores web baseados no EC2, então minha experiência é de muitas horas, mas é limitada ao CentOS; especificamente a distribuição da Amazon. Estou instalando o Apache usando o yum, portanto, obtendo a compilação padrão do Apache da Amazon.

Eu quero implementar redirecionamentos canônicos de domínio não-www (bare / root) para www.domain.com para SEO usando mod_rewrite MAS MY .htaccess FILE É CONSISTENTEMENTE IGNORADO.

Minhas etapas de solução de problemas (descritas abaixo) me levam a acreditar que é algo específico para a compilação do Apache na Amazon.

CASO DE TESTE

1. Iniciar uma Instância do EC2, por exemplo %código%
2. SSH para o servidor

3. Execute os comandos:

   • Amazon Linux AMI 2013.03.1
   • $ sudo yum install httpd
   • $ sudo apachectl start
   • $ sudo vi /etc/httpd/conf/httpd.conf
   • $ sudo apachectl restart

No httpd.conf eu mudei o seguinte, na seção / escopo DOCROOT:

AllowOverride All

No .htaccess, adicionado:

(EDIT, adicionei $ sudo vi /var/www/html/.htaccess depois)

RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
RewriteRule ^/(.*) http://www.domain.com/$1 [R=301,L]

As permissões no .htaccess estão corretas, o AFAI pode dizer:

RewriteEngine On

Outras informações:

$ httpd -v
Server version: Apache/2.2.24 (Unix)
Server built:   May 20 2013 21:12:45

$ httpd -M
Loaded Modules:
 core_module (static)
     ...
 rewrite_module (shared)
     ...
 version_module (shared)
Syntax OK

COMPORTAMENTO ESPERADO

$ curl -I domain.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 19 Jun 2013 12:36:22 GMT
Server: Apache/2.2.24 (Amazon)
Location: http://www.domain.com/
Connection: close
Content-Type: text/html; charset=UTF-8

COMPORTAMENTO REAL

$ curl -I domain.com
HTTP/1.1 200 OK
Date: Wed, 19 Jun 2013 12:34:10 GMT
Server: Apache/2.2.24 (Amazon)
Connection: close
Content-Type: text/html; charset=UTF-8

ETAPAS DE SOLUÇÃO DE PROBLEMAS

No .htaccess, adicionado:

BLAH BLAH BLAH ERROR
RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
RewriteRule ^/(.*) http://www.domain.com/$1 [R=301,L]

Meu servidor jogou um erro 500, então eu sabia que o arquivo .htaccess foi processado.

Como esperado, ele criou uma entrada de log de erros:      $ ls -al /var/www/html/.htaccess -rwxrwxr-x 1 git apache 142 Jun 18 22:58 /var/www/html/.htaccess

Como tenho acesso root no servidor, tentei mover minha regra de reescrita diretamente para o arquivo httpd.conf. Isso funcionou. Isso nos diz que várias coisas importantes estão funcionando.

$ curl -I domain.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 19 Jun 2013 12:36:22 GMT
Server: Apache/2.2.24 (Amazon)
Location: http://www.domain.com/
Connection: close
Content-Type: text/html; charset=UTF-8

No entanto, está me incomodando que não funcionou no arquivo .htaccess. E tenho outros casos de uso em que preciso que funcionem no .htaccess (por exemplo, uma instância do EC2 com hosts virtuais nomeados).

Agradecemos antecipadamente por sua ajuda.

    

Answer 1

Você pode colocar RewriteRules na configuração do servidor ou no .htaccess. No entanto, existem diferenças que significam que uma regra que funciona em uma configuração de servidor não funcionará necessariamente no contexto .htaccess ou vice-versa. RewriteRules em arquivos .htaccess (e contexto de diretório) são comparados com URLs relativos, então sua regra começando com / nunca é correspondida. Ative o rewritelog e você verá.

Assim, para o asume, o docroot é / var / www e você solicita o link

Uma regra de reescrita na configuração do seu servidor será comparada com /foo/bar.html

Uma regra de reescrita em um contexto, ou em um arquivo .htaccess em / var / www / foo será comparada apenas com bar.html. Então, se começar com um / não será compatível.

É importante estar ciente disso, e uma das razões pelas quais eu geralmente considero reescrever os arquivos do .htaccess é uma má ideia. Eu costumo aconselhar strongmente contra reescrever os arquivos .htaccess se você puder evitá-lo (e você tem acesso ao httpd.conf para que você possa). RewriteRules em arquivos .htaccess geralmente levam a um comportamento difícil de diagnosticar e são um grande sucesso no desempenho.

Veja também a documentação do apache: link

"In Directory and htaccess context, the Pattern will initially be matched against the filesystem path, after removing the prefix that led the server to the current RewriteRule (e.g. "app1/index.html" or "index.html" depending on where the directives are defined)."