Przełączanie agenta użytkownika w trakcie żądania?

Mam tu naprawdę dziwny problem - aplikacja Webforms ASP.NET 3.5 na serwerze IIS 6.Przełączanie agenta użytkownika w trakcie żądania?

Efekt jest taki, że użytkownik łączy się z naszą witryną i pobiera sesję ASP.NET, wprowadza niektóre dane i nagle wszystkie jego dane wprowadzone (i zapisane w sesji) zniknęły.

Dziennik błędów pokazuje nam, że z jakiegoś dziwnego powodu właśnie rozpoczyna nową sesję w trakcie pracy nad aplikacją.

Z dzienników IIS, widzimy, że obrębie pojedynczego żądania ASP.NET, agent użytkownika zgłaszane z przeglądarki użytkownika przełącza - od MSIE+7.0 do MSIE+8.0 .... jak to możliwe?

Fragment z dziennika:

07:06:38 GET /SomePage.aspx 80 - x.x.x.139 Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1) 401 
07:06:38 GET /SomePage.aspx 80 DOMAIN\USERNAME x.x.x.139 Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1) 200 

07:06:39 GET /javascript/somefile.js 80 DOMAIN\USERNAME x.x.x.139 Mozilla/4.0+ (compatible;+MSIE+8.0;+Windows+NT+5.1) 200 
(lots more requests for .css, .js, .gif, .jpg - all with MSIE+8.0 ....)

Wydaje się dwa wnioski do .aspx stronie odbywa się w trybie MSIE+7.0, a wszelkie późniejsze wnioski dla plików CSS i JS, jak również GIF grafiki und JPG sprawozdanie MSIE+8.0. ..... WTF?!?!?

Nie jestem pewien, czy to naprawdę jest podstawowa przyczyna nagłej utraty sesji ASP.NET - ale to przełączenie klienta użytkownika samo w sobie pozostawia nam drapanie w głowach ... jakieś pomysły?

Jeśli to zachowanie nie jest przyczyną tych "utraconych sesji" - wszelkie pomysły/wskazówki na temat tego, co może być przyczyną? Nie udało się wygrzebać coś zbyt użyteczny tak daleko stąd, Bing, Google lub innego źródła ....

Aktualizacja: czytam in this forum thread że fakt, agent użytkownika różni się pomiędzy pierwszym GET (który pobiera stronę .aspx), a kolejne żądania GET dla .css, mogą spowodować utratę sesji (jest to jednak środowisko PHP). Czy ktoś może potwierdzić, czy dotyczy to również ASP.NET? (lub pokaż, że to stwierdzenie nie jest prawdziwe)

Jeśli tak naprawdę jest - czy jest jakiś sposób, aby powiedzieć ASP.NET nie, aby rozpocząć nową sesję tylko dlatego, że ciąg agenta użytkownika nie pasuje do poprzedniego żądanie?

Źródło

2013-03-22 marc_s

In-proc lub out-of-proc sesje? Może się to zdarzyć, jeśli Twój AppPool został poddany recyklingowi. – nunespascal

Jeśli użytkownik ma program IE8 działający w trybie zgodności, to wysyła agent użytkownika jako IE7, gdy żąda stron. [IEBlog] (http://blogs.msdn.com/b/ie/archive/2009/01/09/the-internet-explorer-8-user-agent-string-updated-edition.aspx) – nunespascal

@nunespascal: jest w-proc - i tak, recykling puli aplikacji spowodowałby to - ale w ciągu sekundy lub dwóch? Wydaje się, że jest to zbyt szybkie, aby odtworzyć pełną pulę aplikacji .... –

To, co tu opisałeś, brzmi naprawdę dziwnie.

Nie widząc tego w akcji, trudno być pewnym, co się dzieje, ale (wyłączając podszywanie się pod UA) jest tylko jedna rzecz, o której mogę pomyśleć: tryb zgodności.

Nie jestem świadomy IE dostarczania różnych ciągi UA dla różnych typów żądań, nawet w trybie zgodności, ale myślę, że to możliwe.

Ale w każdym razie moja sugestia miałaby na celu uniemożliwienie IE korzystania z trybu zgodności, dodając do strony nagłówek meta X-UA-Compatible. Coś jak to powinno zrobić:

<meta http-equiv="x-ua-compatible" content="IE=edge">

Dodaj go w górnej części sekcji <head> kodu HTML.

To powinno zmusić IE do użycia najlepszego silnika renderującego dla strony. Koniec z trybem zgodności.Więc jeśli jest to przyczyną twojego tajemniczo zmieniającego się łańcucha UA, powinno to rozwiązać.

(Oczywiście, jeśli użytkownik ma przeglądarki, która fałszuje ciąg UA, wszystkie zakłady są wyłączone. Ale nawet wtedy wydaje się dziwne dla nich chce to zrobić w środku sesji)

Źródło

2013-03-22 15:19:09 Spudley

Przełączanie agenta użytkownika w trakcie żądania?

Odpowiedz

Powiązane problemy