Ich habe ein wirklich seltsames Problem hier - ASP.NET 3.5 Webforms App auf IIS 6.
Der Effekt besteht darin, dass der Benutzer eine Verbindung zu unserer Site herstellt und eine ASP.NET-Sitzung abruft, einige Daten eingibt und plötzlich alle Daten, die er eingegeben (und in der Sitzung gespeichert) hat, verloren sind.
Fehlerprotokolle zeigen uns, dass er aus irgendeinem seltsamen Grund gerade eine neue Sitzung mitten in der Arbeit in unserer App bekommt.
Aus den IIS-Protokollen sehen wir, dass innerhalb einer einzelnen ASP.NET-Anfrage der Benutzeragent, der vom Browser des Benutzers berichtet wird, von MSIE+7.0 auf MSIE+8.0 .... wie geht das sein?
Auszug aus dem Protokoll:
%Vor% Es sieht so aus, als würden die zwei Anfragen auf der .aspx Seite im MSIE+7.0 Modus gemacht werden, während alle nachfolgenden Anfragen für CSS und JS Dateien sowie GIF und JPG Grafiken MSIE+8.0 ...... WTF zurückliefern ?!?!?
Ich bin mir nicht sicher, ob das wirklich die Ursache für den plötzlichen Verlust der ASP.NET-Sitzung ist - aber dieser Benutzeragent, der sich selbst umstellt, lässt uns am Kopf kratzen .... irgendwelche Ideen?
Wenn dieses Verhalten nicht die Ursache für diese "verlorenen Sitzungen" ist - irgendwelche Ideen / Hinweise darauf, was dort die Ursache sein könnte? Ich konnte bisher nichts übermäßig Nützliches ausgraben, Bing, Google oder irgendeine andere Quelle ....
Update: Ich lese in diesem Forum-Thread , dass der User-Agent dies ist Unterschied zwischen dem ersten GET (der die Seite .aspx abruft) und den nachfolgenden GET -Anforderungen für .css , .js kann dazu führen, dass die Sitzung verloren geht (dies ist jedoch eine PHP-Umgebung). Kann jemand bestätigen, ob dies auch für ASP.NET gilt? (oder zeigen, dass diese Aussage nicht wahr ist)
Wenn dies wirklich der Fall ist - gibt es eine Möglichkeit, ASP.NET mitzuteilen, nicht eine neue Sitzung zu starten, nur weil die User-Agent-Zeichenfolge nicht mit der vorherigen Anfrage übereinstimmt?
Was Sie hier beschrieben haben, klingt tatsächlich ziemlich seltsam.
Ohne es in Aktion zu sehen, ist es schwierig, sicher zu sein, was vor sich geht, aber (außer UA-Spoofing) gibt es nur eine Sache, die mir hier am Werk sein könnte: Kompatibilitätsmodus.
Ich bin mir nicht bewusst, dass IE verschiedene UA-Strings für verschiedene Anfragetypen bereitstellt, auch im Kompatibilitätsmodus, aber ich denke, es ist möglich.
Aber auf jeden Fall wäre mein Vorschlag, zu verhindern, dass der IE überhaupt den Kompatibilitätsmodus verwendet, indem Sie der Meta-Kopfzeile X-UA-Compatible zu Ihrer Seite hinzufügen. So etwas sollte es tun:
Fügen Sie es am oberen Rand des Abschnitts <head> Ihres HTML-Codes hinzu.
Dies sollte IE zwingen, seine beste Rendering-Engine für die Seite zu verwenden. Kein Kompatibilitätsmodus mehr. Wenn dies der Grund für die geheimnisvolle Änderung der UA-Zeichenkette ist, sollte es das lösen.
(Natürlich, wenn der Benutzer einen Browser hat, der die UA-Zeichenkette spoofiert, sind alle Wetten ausgeschaltet. Aber selbst dann würde es seltsam erscheinen, dass sie das mitten in einer Sitzung machen wollen)
Tags und Links asp.net webforms user-agent