Ich habe gerade einen Server auf Debian Jessie aktualisiert, das Apache 2.4.10 (war 2.2) und PHP 5.6 enthält.
Nun, SSL-Sites senden unter bestimmten Umständen keine Formulare in IE11 und iPad Safari (bei Desktop Safari bin ich mir nicht sicher). Firefox und Chrome sind beide in Ordnung. Wenn es fehlschlägt, wird im IE eine IE-Fehlerseite mit der Meldung „Diese Seite kann nicht angezeigt werden“ angezeigt. Nur um es zu betonen: Ich kann auf die Site zugreifen und das Formular sehen, es ist die Übermittlung des Formulars, die dann fehlschlägt.
Dies hängt in gewisser Weise mit KeepAlive und SSL zusammen. Wenn ich KeepAlive im SSL VirtualHost ausschalte, ist das Problem behoben. (Es wird SNI verwendet, obwohl eine der Sites, die den Fehler anzeigen, die erste SSL-Site ist). Ich verwende mpm-itk (und habe das vor dem Upgrade getan).
In IE11 (unter Windows 7) passiert dies mit * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (Standard) * Formularen mit Datei-Uploads (also enctype=multipart/form-data), * nur, wenn tatsächlich eine Datei bereitgestellt wird (es ist in Ordnung, wenn keine Datei vorhanden ist oder wenn andere Felder vorhanden sind; sogar bei einer 1-Byte-Datei schlägt es fehl, unabhängig von der Dateigröße). * nur, wenn der Upload innerhalb von 60 Sekunden nach Anzeige des Formulars gestartet wird (d. h. es ist in Ordnung, wenn Sie 60 Sekunden warten, bevor Sie auf „Senden“ klicken).
Es gibt keine Hinweise darauf, was fehlgeschlagen ist. In den Serverprotokollen ist nichts zu finden, das darauf hinweist, dass der Server erneut kontaktiert wurde. Der Fehler tritt sofort auf. Im IE-Debugger steht nichts, außer dass in der Ergebnisspalte der Netzwerkseite „(Abgebrochen)“ steht und „Navigation aufgetreten: Datei: dnserror.htm“, was ich als bloße Anzeige der Seite annehme, aber trotz des Namens gibt es meines Wissens keinen DNS-Fehler. Fiddler zeigt keinen Netzwerkverkehr an, wenn ich auf die Schaltfläche „Senden“ klicke. In der Windows-Ereignisanzeige ist nichts Relevantes zu finden. Das ist das Merkwürdigste daran – es scheint, als würde es nicht einmal versucht werden.
Für Apache 2.4 habe ich SSL wie hier empfohlen eingerichtet:https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate. CiperSuite ist gegenüber meinem 2.2-Setup unverändert, aber OCSP-Stapling ist jetzt aktiviert. Die wichtigste Änderung in 2.4 ist TLS1.2 (aber Fidler stuft dies meines Wissens herab, also ist es unwahrscheinlich, dass es daran liegt). HSTS ist aktiviert, war es aber vorher auch. SSLLabs gibt der Site die Bewertung A+ und weist auf keine Fehler hin.
Ich habe versucht, KeepAliveTimeout auf 60 zu ändern und auch das alte BrowserMatch wieder einzusetzen.MSIE.„nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 und BrowserMatch“.MSIE." ssl-unclean-shutdown als Experiment, und ich denke, das hat einen gewissen Effekt, nämlich dass es dann nach dem ersten Versuch funktioniert. Aber der erste Zugriff von einem neu gestarteten Browser schlägt trotzdem fehl. Möglicherweise liegt das daran, dass es den Browser erst nach der SSL-Aushandlung bestimmen kann, und dann ist es zu spät, aber danach hat der Browser mehr Informationen? Es ist auch möglich, dass ich diesen Vorgang nicht in weniger als 60 Sekunden durchziehen kann, sodass das zweite Mal aus diesem Grund sowieso OK ist.
Ich habe eine kleine Testsite erstellt, die das Problem demonstriert:https://iet.davidearl.uk. Es verfügt nur für den Testfall über ein selbstsigniertes Zertifikat, daher wird beim ersten Aufrufen eine Zertifikatswarnung angezeigt. Dies ist jedoch bei den tatsächlichen Websites, auf denen das Problem auftritt, nicht der Fall. Die Serverseite gibt im Testfall lediglich den Dateinamen der übermittelten Datei aus, andernfalls ist nur die HTML-Quelle vorhanden.
Auf dem iPad scheint das Problem eher noch schlimmer zu sein. Es scheint überhaupt nicht möglich zu sein, Formulare zu übermitteln (während sie einwandfrei angezeigt werden, unabhängig davon, ob sie Datei-Uploads enthalten). Manchmal hängt es einfach, manchmal wird eine intern generierte Fehlerseite angezeigt („Safari kann die Seite nicht öffnen, da die Netzwerkverbindung unterbrochen wurde“), je nachdem, wie das Formular aufgebaut ist. Der gemeinsame Faktor ist jedoch, dass es funktioniert, wenn Sie 60 Sekunden warten und dann auf die Schaltfläche „Senden“ klicken. Eine alte Version von Safari für PC (5.1.7) funktioniert jedoch einwandfrei.
IE9 unter (einer anderen Kopie von) Windows 7 verhält sich wie iPad Safari – es bleibt einfach hängen, wenn Sie nicht 60 Sekunden nach der Anzeige des Formulars warten. Microsoft Edge unter Windows 10 und IE auf dem Surface RT-Tablet scheinen auf die gleiche Weise zu versagen wie IE11. Ich habe auch einen Fall beobachtet, in dem ein PHP-Zugriff auf den Server „file_get_contents("https...") konstant genau 60 Sekunden hängen bleibt, bevor er erfolgreich ist, was vorher sofort funktionierte.
Ich habe http://superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages ausprobiert – keine Änderung. Dies hängt vielleicht damit zusammen, aber in diesem Fall hatte „KeepAlive Off“ keine Wirkung. und das vorübergehende Ausschalten der Server-Firewall macht keinen Unterschied: http://serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6-6 Ich habe versucht, die SSLCipherSuite neu zu ordnen, um ECDHE-RSA-AES128-SHA256 weiter oben in der Liste zu platzieren (z. B. wie hier vorgeschlagen: http://serverfault.com/questions/677338/why-is-internet-explorer-11-unable-to-connect-to-https-sites-when-tls-1-2-is-ena) Das Löschen des SSL-Status unter „Interneteigenschaften“ > „Inhalt“ macht keinen Unterschied.
Es gibt eindeutig ein Problem im Zusammenhang mit KeepAlive und SSL, das nicht häufig vorkommt, aber ich bin ratlos, was es ist, und es gibt keine Hinweise, die mir dabei helfen könnten, es herauszufinden. Eine umfangreiche Suche hat nichts Hilfreiches ergeben.
Antwort1
Ich bin auf genau dasselbe Problem gestoßen (und habe mir mehrere Tage lang die Haare darüber gerauft!).
Es stellte sich heraus, dass es sich um einen Fehler in mpm-itk handelt (vgl.http://lists.err.no/pipermail/mpm-itk/2015-September/thread.html). Dieser Fehler wurde nun in der gestern veröffentlichten neuesten Version behoben.
Sie können die neue Version hier herunterladen:http://mpm-itk.sesse.net/, aber Sie müssen es selbst aus dem Quellcode kompilieren. Wenn Sie den Anweisungen in der README-Datei folgen, ist das ziemlich unkompliziert.
Antwort2
Vielen Dank für die Frage! Und anAbonnierenfür die Antwort. Ich verwende auch ITK (weiß nicht, warum das nicht mehr Leute tun – bietet eine sehr nützliche Trennung der Berechtigungen zwischen virtuellen Hosts).
Ich wollte nicht alles neu kompilieren, um diesen Fehler zu beheben, sondern wollte lieber darauf vertrauen, dass er eines Tages in Jessie enthalten sein wird und apt-getdas Problem auf magische Weise behoben wird. Aber meine Kunden können nicht bis dahin warten!
Mir ist aufgefallen, dass bestimmte Versionen von jQuery das Problem unter IE häufiger verursacht haben als andere. Ich habe also die Hälfte meines Problems behoben, indem ich auf die verwendete jQuery-Version zurückgegriffen habe. Aber Safari war immer noch ein Problem – manchmal funktionierte es, manchmal schlug es stillschweigend fehl.
Ich habe dies in der Apache-Konfigurationsdatei zum Laufen gebracht setenvif.conf, die ich wie folgt bearbeitet habe:
BrowserMatch "Mac OS X" nokeepalive
(Diese Idee gebührt anderen Anerkennung)
Auf diese Weise wird Keepalive für Mac-Benutzer deaktiviert. Ich bezweifle zwar nicht, dass dies die Dinge für sie etwas verlangsamt, aber meiner Meinung nach ist es besser, als die UX zu zerstören/nicht zu funktionieren.