.htaccess remover extensão de arquivo php não funciona apenas em heroku

Question

Então eu tenho o código abaixo em meu arquivo .htaccess no meu servidor XAMPP apache local no diretório raiz e ele funciona 100% corretamente. No entanto, quando tento implantar no Heroku, isso não funciona. Eu tentei versões ligeiramente modificadas deste encontrado na internet para executar a mesma coisa, mas nenhum deles parece funcionar. Isso deve remover as extensões de arquivo .php e permitir itens como /api/products/all , em que o arquivo api.php existe e products/all são lidos com PHP $_SERVER['PATH_INFO'] e a saída é retornada com base no que eles são.

Options +MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.php [NC,L]

Eu não sei muito sobre .htaccess , então qualquer ajuda seria apreciada.

    

Answer 1

This is supposed to remove .php file extensions

Bem, falando estritamente, esse código destina-se a adicionar a extensão do arquivo .php novamente (para rotear o URL). (Você já "removeu" fazendo uma solicitação para /api/products/all .)

No entanto, esse código não está fazendo o que você acha que está fazendo. Isso está funcionando apenas no seu servidor local por causa da MultiViews line (parte do mod_negotiation). O código mod_rewrite que segue não está fazendo nada, o que é possivelmente porque isso não está funcionando para você no Heroku?

Se as diretivas mod_rewrite tivessem permissão para serem executadas (ou seja, se MultiViews fosse desativado ), isso reescreveria uma solicitação de /api/products/all a /api/products/all.php , o que claramente não está correto neste exemplo.

Não sei quais outros formatos de URL você está tentando manipular, mas para direcionar especificamente um URL do formulário /api/products/all para /api.php/products/all usando mod_rewrite, você precisaria de algo como o seguinte:

RewriteEngine On
RewriteRule ^(api)/(.+) $1.php/$2 [L]

As diretivas RewriteCond não são obrigatórias se você corresponder apenas a esse URL específico.

...and the "products/all" are just read in with php

Isso é chamado de informações adicionais sobre o nome do caminho e é gerenciado / coletado pelo servidor e passado para o PHP no elemento PATH_INFO do $_SERVER superglobal. Se a informação do caminho é permitida, depende do servidor. (Se não, então essas URLs resultariam em um 404.)

UPDATE # 1:

...if I also have files such as example.js.php (where I use php code, but render them as javascript files) and I would like their .php to be removed so they can be accessed via example.js how would I modify the rewrite rule?

Você pode adicionar um bloco de regras adicional como o seguinte:

RewriteCond %{DOCUMENT_ROOT}/$1.$2.php -f
RewriteRule (.+)\.(js)$ $1.$2.php [L]

Isso intercepta todas as solicitações de .js arquivos e reescreve a solicitação para o arquivo .js.php correspondente, se existir.

Como alternativa, você pode especificar a diretiva RewriteCond da seguinte forma:

RewriteCond %{REQUEST_FILENAME}.php -f

Observe que, se os arquivos .js também estiverem localizados em um caminho de URL que inicie /api/ , essa regra precisará ser anterior à regra acima que roteia suas chamadas de API, para para evitar um conflito.

UPDATE # 2: Você também pode precisar definir o tipo mime correto para esses recursos. (Se funciona ou não com o tipo mime errado depende do navegador.) Como o .js URL está sendo reescrito internamente para um script PHP (por exemplo, .js.php ), o Apache servirá naturalmente isso com text/html mime- type (como faz para todos os arquivos PHP por padrão). Você pode verificar se está definindo explicitamente o cabeçalho Content-Type correto no seu script ou defini-lo em .htaccess usando a diretiva Header (mod_headers). Por exemplo:

<FilesMatch "\.js.php$">
    Header set Content-Type "application/javascript; charset=UTF-8"
</FilesMatch>

Observe que isso funcionará somente no Apache 2.2.12+ (antes dessa versão, simplesmente não era possível definir o Content-Type header com a diretiva Header ).

Note também que o método "mais simples" de definir o tipo mime usando o sinal T no RewriteRule não funciona em um diretório / .htaccess contexto - ele é sobrescrito quando a reescrita processo começa de novo.