Eu tenho o seguinte Server Side Includes dentro de um arquivo .html chamado test.html ...
<!--#include virtual="/cgi-bin/myScript.cgi"-->
<!--#include virtual="/includes/myFile.html"-->
Quando vejo test.html ao vivo no meu navegador, myFile.html está sendo inserido / renderizado, mas myScript.cgi está me dando
[an error occurred while processing this directive]
Na barra de endereço do navegador, /cgi-bin/myScript.cgi está processando a saída corretamente, provando que o arquivo existe no caminho e as permissões estão corretas (755).
Os manipuladores SSI estão definidos corretamente, pois o myFile.html está bem incluído, provando que a página está sendo analisada.
Então, se o SSI está funcionando e o myScript.cgi está funcionando, por que o #include virtual não está trabalhando nesse script?
Como uma nota secundária, esta é uma conta de hospedagem cPanel e eu tenho muitas outras contas (sites) no servidor na mesma empresa de hospedagem com a mesma configuração. Os outros estão todos trabalhando como esperado.
O script simplesmente retorna o ano da data de hoje como texto formatado. A saída é precedida por Content-type: text/html\n\n e não é um novo script Perl. Está funcionando nas outras contas.
Minha empresa de hospedagem escalou o problema para o cPanel e, para meu constrangimento, acabou sendo uma configuração no arquivo .htaccess que estava faltando.
A conta que estava trabalhando tinha essa linha, em que a conta quebrada não ...
Options All -Indexes
All , por padrão, inclui o que a empresa de hospedagem adicionou para que funcione ...
Options +Includes +ExecCGI
Sem +ExecCGI , ele quebra como descrevi em minha postagem original.
Boa solução de problemas ao descobrir que seus SSIs funcionam.
Você localizou o problema no subsistema CGI.
Primeiro de tudo, você precisa ter certeza de que você configurou isso no seu arquivo .htaccess :
Options ExecCGI
Se o problema persistir, você precisará examinar seu registro de erros para descobrir o motivo:
This error message is the same as a 500 error (which is generally what you get with errors in .htaccess itself) so the logs are where you will find the descriptive error message.
O cPanel permite que você veja seus registros de erros.
Eles são seus melhores amigos.
Na seção de log de erros, o cPanel mostrará o endereço IP do seu cliente que você está procurando - na parte superior. Este é o endereço IP atribuído pelo seu ISP.
As versões modernas do cPanel (como a que eu uso no Bluehost, nov. 2017) destacam as entradas do seu cliente, para que as tentativas de invasão não o distraiam. Se você não tem destaque, use a função Ctrl-F (Find) do seu navegador para localizar entradas vindas de você.
See the end of this answer for an example of all the hacking attempts they deal with. It is worth every penny to let them handle it rather than to try to run your own server out in the wild.
RESPOSTA: Acredito que o uso de <!--#Include para CGI é o problema.
A maioria dos servidores Apache modernos precisam que você use:
<!--#exec cgi="/cgi-bin/myScript.cgi" -->
em vez de simplesmente incluir o script.
== > Certifique-se de que seu arquivo HTML tenha uma extensão .shtm ou .shtml .
Observe que todos os arquivos /cgi-bin/ precisam ter 755 permissões. - isso significa que o RWX for Owner e o RX for Group & Público
chmod 755 /cgi-bin/*
Isso mostra por que é bom usar um serviço de hospedagem em vez de executar seu próprio servidor.
Exemplo de saída de log de tentativas de invasão, principalmente bloqueada pela RBL:
