IE9- und Apache-SSL-Nokeepalive-Einstellungen


8

Derzeit verwende ich Apache 2.2.3 und CentOS 5.4 für meine PHP-Anwendungen (PHP läuft auf 5.3.7) und die Anwendung läuft auf HTTPS und mit Root-CA-Zertifikat.

Das Problem ist, dass wir einige seltsame Probleme mit IE9 hatten (nur IE9). Wenn der IE9-Browser eine HTTPS-Anfrage an unseren Server sendet, erfolgt manchmal keine HTTPS-Antwort. Was mir aufgefallen ist, dass IE9 die Seite aktualisiert. Genauer gesagt handelt es sich bei der genannten Seite um eine Anmeldeseite. Wenn ich also Benutzername und Passwort eingebe und das Formular abschicke, aber keine Antwort erfolgt und IE9 die gleiche Anmeldeseite erneut zu laden scheint. (mit leerem Benutzernamen und Passwort)

Bei der Rückverfolgung von der Anwendungsebene aus stelle ich fest, dass ich den Benutzernamen und das Kennwort erhalten habe und die Anwendung fehlerfrei beendet wurde.

Das Hauptproblem ist, dass es nicht jedes Mal reproduziert werden kann. Manchmal können wir uns ohne Probleme anmelden, aber manchmal hat es das oben erwähnte Problem.

Jetzt hat unser Unternehmen ein Netzwerkteam, Entwickler und andere Teams. Unser Apache läuft unter einem Load Balancer. Die Netzwerk-Leute behaupten, dass sie niemals Einstellungen ändern, die einzige Änderung ist unsere Anwendung. Aus Entwicklersicht hatten die Änderungen jedoch nichts mit dem Anmeldevorgang zu tun.

Aus meiner Sicht scheint es so, als ob ein Benutzer, sobald er auf Senden geklickt hat, und die Anwendung (Apache) das getan hat, was sie getan hat, indem sie einen HTML-Code (HTTPS-Antwort) gesendet hat, aber der HTML-Code ist auf wundersame Weise im Netzwerk verschwunden. Ich vermute, dass es etwas mit der Verbindung zu tun hat? Wahrscheinlich geht der IE9-Browser-Agent anders damit um, und irgendwie scheint die Verbindung fehlgeschlagen zu sein, und die Seite wird erneut geladen, um es erneut zu versuchen.

Trotzdem habe ich in Apache die folgenden Einstellungen für die SSL-Verbindung bemerkt:

SetEnvIf User-Agent ". MSIE. " \ Nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0

Sie sind sich nicht sicher, wie wir so einrichten können, dass IE9 und höher ausgeschlossen werden? Wenn ich eine Suche durchführe, dienen die oben genannten Einstellungen dazu, ein langjähriges Problem zu beheben, wenn der IE eine Verbindung mit Apache herstellt. Aber da IE9 ziemlich brandneu ist, ist das Problem wahrscheinlich bereits behoben und wir müssen die Einstellungen aktualisieren?

Hoffentlich kann jemand Licht ins Dunkel bringen.



blogs.msdn.com/b/ieinternals/archive/2011/03/26/… Es wurde dieser Link gefunden, der vorschlug, die Änderung an BrowserMatch vorzunehmen ". * MSIE [2-5] \ .. *" \ nokeepalive ssl-unclean -shutdown \ downgrade-1.0 Force-Response-1.0, benötigt aber Zeit, um es zu testen. In der Zwischenzeit nicht sicher, ob jemand auch ähnliche Probleme hat und was er tut, um es zu lösen.
Forestclown

Was lässt Sie vermuten, dass Keep-Alive verwandt ist? Können Sie eine Erfassung des Netzwerkverkehrs durchführen, um dies zu bestätigen?
Shane Madden

Ist nur eine wilde Vermutung, weil es nur in IE9 passiert, und in Bezug auf Apache-Setup ist dies derzeit das einzige Setup, das ich bemerkt habe, das etwas speziell für IE tut ...
Forestclown

Hast du das jemals gelöst? Was war die Lösung?

Antworten:


3

Höchstwahrscheinlich hat das Server- / Netzwerk-Setup irgendwo ein Problem und wird nicht durch IE9-Macken verursacht.

Entfernen Sie zunächst die alte Konfiguration vor IE6: SetEnvIf User-Agent ".MSIE." \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0und versuchen Sie einfach, sie überhaupt nicht auszuführen (in jeder Form). Es sei denn, Sie müssen IE5 unterstützen, was ich bezweifle, dass Sie dies tun. In diesem Fall ist es richtig, den regulären Ausdruck in zu ändernMSIE [2-5]

Der Load Balancer und ohne Keepalive ist wahrscheinlich das Problem. Ich wäre dem Load Balancer gegenüber sehr misstrauisch und würde zuerst genau prüfen, was dort vor sich geht.

Ein Load Balancer verteilt normalerweise die Last zwischen zwei oder mehr IP-Adressen (intern oder extern spielt dies an dieser Stelle keine Rolle).

Wenn die Verbindungen zwischen Anforderungen nicht eingehalten werden, muss der Client-Computer / Browser für jede Anforderung eine SSL-Aushandlung durchführen. Wenn Sie dies mit Einstellungen für Langsamkeit und geringes Zeitlimit kombinieren, können Probleme mit der Nichtübereinstimmung von SSL-Zertifikaten auftreten, und der IE wird wahrscheinlich aufgrund strenger Sicherheitseinstellungen eingerichtet. Ich habe nicht genau untersucht, ob IE9 nur dieses Merkmal hat. Ich würde vermuten, dass andere Browser dies auch tun und anders damit umgehen.

Wenn Sie SSL verwenden, sollte KeepAlive aktiviert sein, da dies die Site viel schneller macht und nicht immer wieder SSL-Verhandlungen führen muss, was fehlschlägt, da der Load Balancer die Sitzung während der Lebensdauer des Besuchers nicht auf demselben Server hält .

Wenn Ihre Anwendung intern ist (in einem Intranet), springt Ihr Load Balancer zufällig IP-Adressen auf Sie und SSL muss für jede Verbindung identisch sein.

Wenn es sich nicht in einem Intranet befindet, könnte das auch zutreffen. Ich weiß nicht, wie Ihr Netzwerk eingerichtet ist, aber Sie sollten dies zuerst überprüfen. Deaktivieren Sie den Load Balancer und prüfen Sie, ob das Problem vorliegt. und auf jeden Fall weiterleben.

http://httpd.apache.org/docs/2.2/mod/core.html#keepalive

Ich würde auch prüfen, ob Sie überhaupt Reverse-DNS-Setup haben. Wenn es auf den Load Balancer oder den Server hinter dem Load Balancer zeigt oder was nicht.

Testen Sie Ihre Verbindung und analysieren Sie Ihre Header, wenn Sie extern etwas wie redbot.org oder webpagetest.org verwenden , um zu überprüfen, welche Header gesendet werden. Sie können auch so etwas wie Geiger verwenden


1
ssl-unclean-shutdown ist weiterhin erforderlich für IE> = 6 alexmeyer.com/linux/apachekeepalive.html
user2299634
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.