Acabei de atualizar um servidor para Debian Jessie, que inclui Apache 2.4.10 (era 2.2) e PHP 5.6.
Agora, os sites SSL não enviam formulários em algumas circunstâncias no IE11 e no iPad Safari (não tenho certeza sobre o Safari para desktop). Firefox e Chrome estão OK. Quando falha, produz uma página de erro do IE “Esta página não pode ser exibida” no IE. Só para enfatizar: posso chegar ao site e ver o formulário, é o envio do formulário que falha.
Isso está relacionado ao KeepAlive e ao SSL de alguma forma. Se eu desligar o KeepAlive no SSL VirtualHost, o problema desaparecerá. (Está usando SNI, embora um dos sites que mostram o erro seja o primeiro SSL). Estou usando o mpm-itk (e estava antes da atualização).
No IE11 (no Windows 7), isso acontece com * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (o padrão) * formulários com uploads de arquivos (então enctype=multipart/form-data), * somente quando um arquivo é realmente fornecido (não há problema em nenhum arquivo com ou com outros campos; mesmo um arquivo de 1 byte causa falha, não depende do tamanho do arquivo). * somente se o upload for iniciado dentro de 60 segundos após a exibição do formulário (ou seja, não há problema se você esperar 60 segundos antes de pressionar Enviar)
Não há pistas sobre o que falhou. Não há nada nos logs do servidor que mostre que ele entrou em contato com o servidor novamente. O erro é imediato. Não há nada no depurador do IE além de dizer "(Abortado)" na coluna de resultados da página de rede e "Navegação ocorrida: Arquivo: dnserror.htm" que presumo ser apenas a página que está exibindo, mas apesar do nome, não há erro de DNS, pelo que eu saiba. O Fiddler não mostra tráfego de rede quando pressiono o botão enviar. Não há nada relevante no visualizador de eventos do Windows. Esta é a coisa mais estranha sobre isso - nem parece tentar.
Para o Apache 2.4, configurei o SSL conforme recomendado aqui:https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate. O CiperSuite permanece inalterado em relação à minha configuração 2.2, mas a gravação OCSP agora está ativada. A principal alteração do 2.4 é o TLS1.2 (mas Fidler faz o downgrade disso, acredito, então é improvável que seja isso). O HSTS está ativado, mas estava anteriormente. SSLLabs atribui ao site uma classificação A+ e não indica nenhum erro.
Tentei alterar KeepAliveTimeout para 60; e também colocando de volta no antigo BrowserMatch ".MSIE." nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 e BrowserMatch ".MSIE." ssl-unclean-shutdown como um experimento, e acho que isso tem algum efeito, ou seja, funciona após a primeira tentativa. Mas o primeiro acesso de um navegador recém-iniciado ainda falha. Possivelmente porque não consegue determinar navegador até depois da negociação SSL, quando já é tarde demais, mas depois disso o navegador tem mais informações. Também é possível que eu não consiga passar por esse processo em menos de 60 segundos, então a segunda vez está OK por causa disso.
Fiz um pequeno site de teste que demonstra o problema:https://iet.davidearl.uk. Ele possui um certificado autoassinado apenas para o caso de teste, portanto, há um aviso de certificado ao acessá-lo pela primeira vez, mas esse não é o caso dos sites reais que apresentam o problema. Tudo o que o lado do servidor faz no caso de teste é repetir o nome do arquivo enviado, caso contrário, a fonte HTML é tudo o que existe.
No iPad, o problema parece pior, na verdade. Parece não ser possível enviar formulários (embora os exiba corretamente; independentemente de terem uploads de arquivos). Às vezes ele simplesmente trava, às vezes tem uma página de erro gerada internamente ("O Safari não consegue abrir a página porque a conexão de rede foi perdida"), dependendo de como o formulário é construído. Novamente, porém, o fator comum é que se você esperar 60 segundos e pressionar o botão enviar, ele funciona. Uma versão antiga do Safari para PC (5.1.7) funciona bem.
O IE9 no (uma cópia diferente do) Windows 7 se comporta como o iPad Safari - ele simplesmente trava, a menos que você espere 60 segundos após exibir o formulário. O Microsoft Edge no Windows 10 e o IE no tablet Surface RT também parecem falhar da mesma forma que o IE11. Também observei um caso em que um PHP "file_get_contents("https..." acessando o servidor trava consistentemente por exatamente 60 segundos antes de ter sucesso, o que funcionou instantaneamente anteriormente.
Eu tentei http: // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - sem alteração Isso talvez esteja relacionado, mas em o caso deles, KeepAlive Off, não teve efeito; e desligar o firewall do servidor temporariamente não faz diferença: http: // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6- 6 Tentei reordenar o SSLCipherSuite para colocar ECDHE-RSA-AES128-SHA256 no topo da lista (por exemplo, como sugerido aqui: http: // serverfault.com/questions/677338/why-is-internet-explorer-11- incapaz de conectar-se a https-sites-quando-tls-1-2-is-ena) Limpar estado SSL nas propriedades da Internet> O conteúdo não faz diferença.
Há claramente um problema relacionado ao KeepAlive e ao SSL, que não é comum, mas estou confuso sobre o que é e não há pistas que me ajudem a descobrir. Uma pesquisa extensa não rendeu nada útil.
Responder1
Encontrei exatamente o mesmo problema (passei alguns dias puxando meu cabelo nesse caso!).
Acontece que é um bug no mpm-itk (cf.http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). Este bug foi corrigido na última versão lançada ontem.
Você pode baixar esta nova versão emhttp://mpm-itk.sesse.net/, mas você mesmo terá que compilá-lo a partir do código-fonte. É bastante simples se você seguir as instruções no arquivo README.
Responder2
Obrigado pela Q! E paracidadepara a resposta. Eu também uso o ITK (não sei por que mais pessoas não o fazem - oferece uma separação útil de privilégios entre hosts virtuais).
Eu não queria recompilar coisas para eliminar esse bug, preferindo confiar que um dia ele chegaria a Jessie e apt-geto consertaria magicamente. Mas meus clientes não podem esperar até lá!
Percebi que certas versões do jQuery faziam com que isso acontecesse mais do que outras, no IE. Então resolvi metade do meu problema voltando à versão do jQuery usada. Mas o Safari ainda era um problema - às vezes funcionava, às vezes falhava silenciosamente.
A maneira como fiz isso funcionar foi no setenvif.confarquivo de configuração do Apache que editei para incluir:
BrowserMatch "Mac OS X" nokeepalive
(crédito devido em outro lugar por esta ideia)
Dessa forma, o keepalive está desativado para usuários de Mac. Embora eu não tenha dúvidas de que isso retarda um pouco as coisas para eles, é melhor do que matar o UX/não funcionar na IMO.