방금 서버를 Apache 2.4.10(기존 2.2)과 PHP 5.6이 포함된 Debian Jessie로 업그레이드했습니다.
이제 SSL 사이트는 IE11 및 iPad Safari의 일부 상황에서 양식을 제출하지 않습니다(데스크톱 Safari는 확실하지 않음). 파이어폭스와 크롬 모두 괜찮습니다. 실패하면 IE에서 "이 페이지를 표시할 수 없습니다"라는 IE 오류 페이지가 생성됩니다. 강조하자면, 사이트에 접속하여 양식을 볼 수 있는데 양식 제출이 실패한다는 것입니다.
이는 어떤 방식으로든 KeepAlive 및 SSL과 관련이 있습니다. SSL VirtualHost에서 KeepAlive를 끄면 문제가 사라집니다. (오류를 표시하는 사이트 중 하나가 첫 번째 SSL 사이트이지만 SNI를 사용하고 있습니다.) 저는 mpm-itk를 사용하고 있습니다(업그레이드 전이었습니다).
IE11(Windows 7)에서는 * SSL(HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5(기본값) * 파일 업로드가 포함된 양식(enctype=multipart/form-data)에서 발생합니다. * 파일이 실제로 제공됩니다(파일이 없거나 다른 필드가 있어도 괜찮습니다. 1바이트 파일이라도 파일 크기에 따라 다르지 않고 실패하게 됩니다). * 양식을 표시한 후 60초 이내에 업로드가 시작된 경우에만 해당됩니다(예: 제출을 누르기 전 60초 동안 그대로 놔두어도 괜찮습니다).
무엇이 실패했는지에 대한 단서는 없습니다. 서버 로그에는 서버에 다시 연결되었음을 나타내는 내용이 없습니다. 오류는 즉시 발생합니다. IE 디버거에는 네트워크 페이지의 결과 열에 "(중단됨)"이라고 표시되고 "탐색 발생: 파일: dnserror.htm"이 표시되는 페이지일 뿐이라고 가정하는 것 외에는 아무것도 없습니다. 내가 알 수 있는 한 DNS 오류는 없습니다. 제출 버튼을 눌렀을 때 Fiddler에 네트워크 트래픽이 표시되지 않습니다. Windows 이벤트 뷰어에는 관련 내용이 없습니다. 이것이 가장 이상한 점입니다. 시도조차 하지 않는 것 같습니다.
Apache 2.4의 경우 여기에서 권장하는 대로 SSL을 설정했습니다.https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate. CiperSuite는 2.2 설정에서 변경되지 않았지만 이제 OCSP 스테이핑이 켜져 있습니다. 2.4의 주요 변경 사항은 TLS1.2입니다(그러나 Fidler는 이를 다운그레이드하므로 그럴 가능성은 낮습니다). HSTS가 켜져 있지만 이전에는 켜져 있었습니다. SSLLabs는 사이트에 A+ 등급을 부여하고 오류를 표시하지 않습니다.
KeepAliveTimeout을 60으로 변경해 보았습니다. 또한 이전 BrowserMatch를 다시 넣습니다."MSIE." nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 및 BrowserMatch ".MSIE." ssl-unclean-shutdown을 실험적으로 사용했는데 이것이 어느 정도 효과가 있다고 생각합니다. 즉, 첫 번째 시도 후에 작동한다는 것입니다. 그러나 새로 시작한 브라우저에서 첫 번째 액세스는 여전히 실패합니다. 아마도 이는 확인할 수 없기 때문일 수 있습니다. SSL 협상이 끝날 때까지는 너무 늦었지만 그 이후에는 브라우저에 더 많은 정보가 있을 수도 있습니다. 이 프로세스를 60초 이내에 완료할 수 없으므로 어쨌든 두 번째는 괜찮습니다.
나는 문제를 보여주는 작은 테스트 사이트를 만들었습니다.https://iet.davidearl.uk. 테스트 사례만을 위한 자체 서명 인증서가 있으므로 처음 방문할 때 인증서 경고가 표시되지만 문제가 있는 실제 사이트에서는 그렇지 않습니다. 테스트 케이스에서 서버 측이 수행하는 모든 작업은 제출된 파일의 파일 이름을 에코하는 것입니다. 그렇지 않으면 HTML 소스가 전부입니다.
iPad에서는 문제가 더 심각해 보입니다. 양식을 전혀 제출할 수 없는 것 같습니다(파일 업로드 여부에 관계없이 잘 표시되지만). 가끔은 그냥 멈추기도 하고, 때로는 양식 구성 방식에 따라 내부적으로 생성된 오류 페이지("네트워크 연결이 끊어졌기 때문에 Safari에서 페이지를 열 수 없습니다")가 나타날 수도 있습니다. 하지만 여기서도 공통적인 점은 60초를 기다린 후 제출 버튼을 누르면 작동한다는 것입니다. 하지만 이전 버전의 PC용 Safari(5.1.7)는 정상적으로 작동합니다.
Windows 7(다른 복사본)의 IE9는 iPad Safari처럼 작동합니다. 양식을 표시한 후 60초를 기다리지 않으면 작동이 멈춥니다. Windows 10의 Microsoft Edge와 Surface RT 태블릿의 IE도 IE11과 같은 방식으로 실패하는 것 같습니다. 나는 또한 서버에 액세스하는 PHP "file_get_contents("https..."가 성공하기 전에 정확히 60초 동안 지속적으로 중단되는 경우를 관찰했습니다. 이전에는 즉시 작동했습니다.
나는 http를 시도했습니다 : // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - 변경 없음 이것은 아마도 관련이 있지만 KeepAlive Off의 경우에는 효과가 없었습니다. 서버 방화벽을 일시적으로 꺼도 아무런 차이가 없습니다. http : // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6- 6 ECDHE-RSA-AES128-SHA256을 목록의 상위 항목에 추가하기 위해 SSLCipherSuite를 다시 주문해 보았습니다(예: 여기에서 제안한 대로: http : // serverfault.com/questions/677338/why-is-internet-explorer-11- could-to-connect-to-https-sites-when-tls-1-2-is-ena ) 인터넷 속성에서 SSL 상태 지우기 > 콘텐츠는 아무런 차이가 없습니다.
KeepAlive 및 SSL과 관련된 문제가 분명히 있습니다. 이는 일반적이지 않지만 문제가 무엇인지 알 수 없으며 알아내는 데 도움이 되는 단서가 없습니다. 광범위한 검색을 통해 도움이 되는 결과가 나오지 않았습니다.
답변1
나는 똑같은 문제에 직면했습니다. (이 문제로 머리를 당기는 데 꽤 며칠이 걸렸습니다!)
mpm-itk의 버그인 것으로 밝혀졌습니다(참조:http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). 이 버그는 어제 출시된 최신 버전에서 수정되었습니다.
이 새 버전은 다음에서 다운로드할 수 있습니다.http://mpm-itk.sesse.net/, 그러나 소스에서 직접 컴파일해야 합니다. README 파일의 지침을 따르면 매우 간단합니다.
답변2
Q 감사합니다! 그리고시비데스크대답을 위해. 나도 ITK를 사용합니다(왜 더 많은 사람들이 사용하지 않는지 잘 모르겠습니다. v 가상 호스트 간의 유용한 권한 분리를 제공합니다).
나는 이 버그를 없애기 위해 물건을 다시 컴파일하고 싶지 않았고 언젠가 Jessie에 적용되어 apt-get마술처럼 고쳐질 것이라고 믿고 싶었습니다. 하지만 내 고객은 그때까지 기다릴 수 없습니다!
IE에서 특정 버전의 jQuery가 다른 버전보다 더 많이 발생한다는 것을 알았습니다. 그래서 나는 사용된 jQuery 버전을 다시 사용하여 문제의 절반을 해결했습니다. 그러나 Safari는 여전히 문제였습니다. 때로는 작동이 때로는 자동으로 실패하기도 했습니다.
이 작업을 수행하는 방법은 다음 setenvif.conf을 포함하도록 편집한 Apache 구성 파일에 있었습니다.
BrowserMatch "Mac OS X" nokeepalive
(이 아이디어는 다른 곳에서 크레딧을 받을 수 있습니다.)
이렇게 하면 Mac 사용자의 경우 Keepalive가 꺼집니다. 이로 인해 작업 속도가 약간 느려진다는 것은 의심의 여지가 없지만 UX를 종료하거나 IMO가 작동하지 않는 것보다 낫습니다.