我剛剛將伺服器升級到 Debian Jessie，其中包括 Apache 2.4.10（以前是 2.2）和 PHP 5.6。
現在，SSL 網站在某些情況下不會在 IE11 和 iPad Safari 上提交表單（不確定桌面版 Safari 是否如此）。 Firefox 和 Chrome 都可以。當它失敗時，它會在 IE 中產生 IE 錯誤頁面「此頁面無法顯示」。只是強調一下：我可以訪問該網站並查看表單，但表單提交失敗了。
這在某種程度上與KeepAlive和SSL有關。如果我在 SSL VirtualHost 中關閉 KeepAlive，問題就會消失。 （它使用 SNI，儘管顯示錯誤的站點之一是第一個 SSL 站點）。我正在使用 mpm-itk （並且是在升級之前）。
在IE11（在Windows 7 上）中，它發生在* SSL (HTTPS) * Apache KeepAlive On，KeepAliveTimeout 5（預設值） * 帶有檔案上傳的表單（因此enctype=multipart/form-data）， * 僅當文件實際存在時提供（沒有包含或包含其他欄位的文件也沒關係；即使是 1 位元組文件也會導致失敗，與文件大小無關）。 * 僅在顯示表單後 60 秒內開始上傳時（即，如果您在按「提交」之前將其保留 60 秒，則可以）
沒有任何線索表明失敗的原因。伺服器日誌中沒有任何內容表明它再次聯繫了伺服器。錯誤是立即發生的。 IE 偵錯器中沒有任何內容，除了在網頁頁面的結果列中顯示“（中止）”和“導航發生：檔案：dnserror.htm”之外，我認為這只是它正在顯示的頁面，但儘管據我所知，name 沒有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 stapping 現已啟用。 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 協商之後就太晚了，但之後瀏覽器有更多資訊？
我做了一個小測試網站來示範這個問題：https://iet.davidearl.uk。它有一個僅用於測試案例的自簽名證書，因此第一次訪問時會出現證書警告，但存在問題的真實網站並非如此。伺服器端在測試案例中所做的只是回顯所提交文件的文件名，否則就是 HTML 原始碼。
在 iPad 上，這個問題似乎更嚴重（如果有的話）。它似乎根本無法提交表單（同時顯示它們很好；無論它們是否有文件上傳）。有時它只是掛起，有時它有一個內部生成的錯誤頁面（“Safari 無法打開頁面，因為網絡連接丟失”），具體取決於表單的構造方式。不過，共同點是，如果您等待 60 秒，然後按提交按鈕，它就會起作用。不過，舊版 Safari for PC (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 我嘗試重新排序SSLCipherSuite，將ECDHE-RSA-AES128-SHA256 放在清單的較高位置（例如，按照此處的建議：http://serverfault.com/questions/677338/why-is-internet-explorer-11 -無法連線到 https-sites-when-tls-1-2-is-ena ) 在 Internet 屬性 > 內容上清除 SSL 狀態沒有任何差異。
顯然存在與 KeepAlive 和 SSL 相關的問題，這並不常見，但我對它是什麼感到困惑，也沒有任何線索可以幫助我找出答案。廣泛的搜索沒有產生任何有用的結果。
答案1
我遇到了完全相同的問題（花了好幾天的時間在這個問題上拉扯我的頭髮！）。
事實證明這是 mpm-itk 中的一個錯誤（參見http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html）。該錯誤現已在昨天發布的最新版本中修正。
您可以在以下位置下載這個新版本：http://mpm-itk.sesse.net/，但您必須自己從原始程式碼編譯它。如果您按照自述文件中的說明進行操作，則非常簡單。
答案2
謝謝你的Q！並公民服務台答案。我也使用 ITK（不知道為什麼更多的人不這樣做——在虛擬主機之間提供了有用的權限分離）。
我不想重新編譯東西來消除這個錯誤，而是更願意相信有一天它會進入 Jessie 並apt-get神奇地修復它。但我的客戶等不及那時了！
我注意到，在 IE 下，某些版本的 jQuery 比其他版本更容易導致這種情況發生。所以我透過使用 jQuery 版本解決了一半的問題。但 Safari 仍然是一個問題 - 有時它會工作有時會默默地失敗。
我的工作方式是在 Apache 設定setenvif.conf檔中，我對其進行了編輯，包括：
BrowserMatch "Mac OS X" nokeepalive
這樣 Mac 用戶的 keepalive 就關閉了。雖然我毫不懷疑這會減慢他們的速度，但在我看來，這比殺死用戶體驗/不工作要好。