Parabéns ao @ w3d por apontar isso. O proxy interno da solicitação irá ignorar o arquivo .htaccess. Claro que sim. Eu atualizei meu arquivo VHost para o abaixo, seguindo a resposta deste segmento: Apache 2.4 + PHP-FPM + ProxyPassMatch
Estou tentando descobrir por que meu .htaccess não está sendo considerado ao carregar um arquivo .php. Abaixo, os arquivos estão no webroot do meu host local.
.htaccess
# Cause a HTTP 500
test
file.html
<html><body><h1>This should not show</h1></body></html>
file.php
<html><body><h1>This should not show</h1></body></html>
quando eu acesso /index.html, recebo o HTTP500 esperado Quando eu acesso /index.php, o html mostra.
Alguma idéia de por que o .htaccess não carrega o arquivo PHP?
Apache 2.4.6 VHost (/etc/httpd/vhosts.d/website.local.conf):
<VirtualHost *:443>
ServerName website.local
ServerAlias www.website.local
DocumentRoot /var/www/vhosts/website/website
<Directory /var/www/vhosts/website/website>
require all granted
Options Indexes FollowSymLinks
AllowOverride All
</Directory>
# Trigger PHP-FPM to run PHP execution
<IfModule proxy_fcgi_module>
ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/var/www/vhosts/website/php-fpm.sock|fcgi://website/var/www/vhosts/website/website"
DirectoryIndex index.php
</IfModule>
SSLEngine on
SSLCertificateKeyFile /var/www/ssl/website.key
SSLCertificateFile /var/www/ssl/website.crt
</VirtualHost>
Não há outras configurações de vhost para este site:
[root@localhost ~]# cat /etc/httpd/conf/*.conf | grep website.local
[root@localhost ~]# cat /etc/httpd/vhosts.d/*.conf | grep website.local
ServerName website.local
ServerAlias www.website.local
[root@localhost ~]#
Atualização 1:
Eu habilitei reescrever: nível de log trace3 seguindo as instruções de depuração .htaccess de link . Parece que o arquivo .htaccess não é sequer considerado pelo Apache ao carregar um arquivo PHP:
Acessando "/file.html" - .HTAccess é carregado e o HTTP500 retornado como esperado
==> /var/log/httpd/website-error_log <==
[Thu Jul 07 09:36:02.651091 2016] [core:alert] [pid 2822] [client 10.128.3.189:56406] /var/www/vhosts/website/website/.htaccess: Invalid command 'test', perhaps misspelled or defined by a module not included in the server configuration
==> /var/log/httpd/website-access_log <==
10.128.3.189 - - [07/Jul/2016:09:36:02 +0100] "GET /wp-admin/ HTTP/1.1" 500 527 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
Acessando "file.php" - .HTAccess não está carregado e HTTP200 retornou
==> /var/log/httpd/website-access_log <==
10.128.3.189 - - [07/Jul/2016:09:38:41 +0100] "GET /file.php HTTP/1.1" 200 64057 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.128.3.189 - - [07/Jul/2016:09:38:41 +0100] "GET /file.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2524 "https://www.website.local/file.php" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.128.3.189 - - [07/Jul/2016:09:38:41 +0100] "GET /file.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2146 "https://www.website.local/file.php" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
Acessando "file.jpg" - .HTAccess é carregado e o HTTP500 retornado como esperado
==> /var/log/httpd/website-error_log <==
[Thu Jul 07 09:43:08.403263 2016] [core:alert] [pid 2827] [client 10.128.3.189:56551] /var/www/vhosts/website/website/.htaccess: Invalid command 'sfdgsaga', perhaps misspelled or defined by a module not included in the server configuration
==> /var/log/httpd/website-access_log <==
10.128.3.189 - - [07/Jul/2016:09:43:08 +0100] "GET /file.jpg HTTP/1.1" 500 527 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
Não tenho conhecimento de nenhuma configuração que desautorize o .htaccess para tipos específicos de arquivo / mime. Poderia ser uma questão de em que ordem os módulos são carregados?
Atualização 2: limpou o arquivo vhost acima
Atualização 3: O problema só aparece quando o PHP-FPM está configurado Remover o código abaixo da configuração não ignora mais os arquivos .htaccess
<IfModule proxy_fcgi_module>
ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/var/www/vhosts/website/php-fpm.sock|fcgi://website/var/www/vhosts/website/website"
DirectoryIndex index.php
</IfModule>
Atualização 4: parabéns pelo @ w3d por apontar isso. O proxy interno do pedido irá pular o arquivo .htaccess . Claro que sim. Eu atualizei meu arquivo VHost para o abaixo, seguindo a resposta deste segmento: Apache 2.4 + PHP-FPM + ProxyPassMatch
<VirtualHost *:443>
ServerName website.local
ServerAlias www.website.local
DocumentRoot /var/www/vhosts/website/website
<Directory /var/www/vhosts/website/website>
require all granted
Options Indexes FollowSymLinks
AllowOverride All
</Directory>
ErrorLog "logs/website-error_log"
CustomLog "logs/website-access_log" combined env=!forwarded
CustomLog "logs/website-access_log" proxy env=forwarded
# Proxy set-up as per
# https://serverfault.com/questions/450628/apache-2-4-php-fpm-proxypassmatch
# This is to forward all PHP to php-fpm.
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/www/vhosts/website/php-fpm.sock|fcgi://website/"
</FilesMatch>
# Set some proxy properties (the string "unique-domain-name-string" should match
# the one set in the FilesMatch directive.
<Proxy fcgi://website>
ProxySet connectiontimeout=5 timeout=240
</Proxy>
DirectoryIndex /index.php index.php
# If the php file doesn't exist, disable the proxy handler.
# This will allow .htaccess rewrite rules to work and
# the client will see the default 404 page of Apache
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
RewriteRule (.*) - [H=text/html]
SSLEngine on
SSLCertificateKeyFile /var/www/ssl/website.key
SSLCertificateFile /var/www/ssl/website.crt
</VirtualHost>
Parabéns ao @ w3d por apontar isso. O proxy interno da solicitação irá ignorar o arquivo .htaccess. Claro que sim. Eu atualizei meu arquivo VHost para o abaixo, seguindo a resposta deste segmento: Apache 2.4 + PHP-FPM + ProxyPassMatch
Esta parte da configuração vhosts é relevante quando você acessa o site com https, você deve ter outra instância em vhosts, pode procurar novamente e atualizar sua postagem?