HTTPS falha para um host virtual

Question

OK, isso vai soar como um problema estranho ... Eu hesito em postar aqui, já que não consigo entender como descrevê-lo, e muito menos onde começar a procurar por soluções.

Eu tenho um site (Fedora 24, pilha padrão LAMP, rodando no Amazon EC2) que recentemente começou a responder com páginas em branco quando solicitações via HTTPS foram feitas.

Por exemplo, se você acessou o link , ele funcionará bem, mas http s : //example.com/coolscript.php retorna uma página em branco. Os registros do servidor da Web mostram HTTP 200 para ambos, mas sem dados retornados para a versão HTTPS (o último, abaixo):

1.2.3.4 - - [22/Dec/2016:16:19:39 +0000] "GET /coolscript.php HTTP/1.1" 200 9069 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"
1.2.3.4 - - [22/Dec/2016:16:19:25 +0000] "GET /coolscript.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"

Já experimentei diferentes navegadores, PCs, redes, etc., todos respondem com uma página em branco.

Você pode ser tentado (como eu estava) a pensar que eu tenho algo confuso com as definições de virtualhost no Apache, mas o acesso a arquivos simples (mesmo scripts PHP) funciona bem. O certificado é válido e bom para ir. Outros sites habilitados para HTTPS no mesmo servidor funcionam bem com um certificado diferente e até mesmo com aliases de host virtual usando o mesmo trabalho de certificado. É apenas esse nome de host, em HTTPS, que falha. (Kicker: os aliases que funcionam são definidos na mesma definição de virtualhost que aquela que não funciona.)

Eu olhei para várias áreas diferentes na esperança de encontrar o problema, mas estou perplexo. Sugestões, comentários ou especulação selvagem bem-vindos. :)

UPDATE

Algumas semanas após a publicação original, encontrei o mesmo problema novamente, mas desta vez o HTTP estava falhando e o HTTPS estava bem. Novamente, apenas para um virtualhost (o padrão). Um tcpdump não mostra conteúdo:

HTTP/1.1 200 OK
Date: Thu, 05 Jan 2017 14:33:48 GMT
Server: Apache/2.4.25 (Fedora) OpenSSL/1.0.2j-fips PHP/5.6.29 mod_perl/2.0.10 Perl/v5.22.2
X-Powered-By: PHP/5.6.29
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private
Pragma: no-cache
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Ainda confuso, talvez ainda mais.

8 de fevereiro de 2017 Atualização

O "problema do host virtual vazio" voltou hoje para HTTP apenas em um host virtual. No status do servidor do apache, as conexões ruins são exibidas como:

4-1 26987   0/2/32  R   1.55    3   223 0.0 0.02    0.13    1.2.3.4 http/1.1        
4-1 26987   0/2/22  R   1.47    4   0   0.0 0.01    0.10    1.2.3.4 http/1.1        
4-1 26987   0/1/10  R   0.07    4   2   0.0 0.00    0.19    1.2.3.4 http/1.1    

Em oposição a:

2-1 26210   0/22/73 W   15.51   0   0   0.0 0.06    0.38    1.2.3.4 http/1.1    vhost.com:443   GET /server-status HTTP/1.1

Notavelmente, a coluna VHost está vazia nas conexões ruins, então eu tenho uma nova direção para focar.

Felicidades Mike

    

Answer 1

OK, finalmente encontrei a resposta real : caching

Eu tinha ativado o cache básico (nível 1) em Simple Machines, e ocasionalmente o cache ficava corrompido e fazia com que o site falhasse, sem erros ou saída que eu encontrasse.

O cache é feito por host, portanto, um falharia enquanto os outros estavam bem. Quando o arquivo corrompido no cache expirou, o problema se resolveria.

Minha solução: desabilitar o armazenamento em cache do SMF e o problema não ocorreu novamente.

Silver lining: Eu encontrei e consertei muitas ineficiências do servidor em busca desta! :)

    

Answer 2

Content-Length: 0 se você realmente recebeu o cabeçalho diretamente do Apache httpd (e não algum proxy intermediário) significa que o Apache está no início certo de que não haverá mais dados vindo do PHP. Então o PHP saiu assim que o script foi executado. Você precisa ini_set("log_errors", 1); como Gerald sugeriu.

Além disso, estabeleça o monitoramento de memória, no mínimo, execute vmstat 1 e observe as colunas cache e free durante a solicitação problemática, talvez o script PHP cause falta de memória.

    

Answer 3

Causa provável: Nas versões recentes do systemd, há um limite para o número de "tarefas" que um serviço pode gerar. Para o apache no Fedora 24, ele foi configurado para 512 e estava limitando o servidor até mesmo com uma carga leve. (Uma pista para mim foi a presença de erros "não foi possível" de várias fontes.)

A correção é editar "/usr/lib/systemd/system/httpd.service" e adicionar "TasksMax = infinity" à seção Serviço:

[Service]
TasksMax=infinity

Até agora, tudo bem.