2010-12-01 3 views
1

У нас есть ASP.NET Cookieless сессии (InProc), поэтому URL содержит идентификатор сессии, то есть S (dfasfdafasdfasfa)Как IIS7 определяет тот же сеанс в сценарии без cooki?

У нас также есть несколько клиентов, проходящих через прокси-сервер, где он появляется, как наш веб-сервер не распознает идентификатор сеанса и без данных сеанса, они не могут продолжаться. Я тестировал наши сайты на открытых прокси, и они отлично работают. Но что-то происходит с этим конкретным клиентским прокси-сервером, который вызывает такое поведение.

Я изучил захват пакетов для случаев успеха и сбоев (предоставленных клиентом), а необработанный HTML-код, передаваемый, включая заголовки, является тем же. Прокси-сервер, похоже, не кэширует URL-адреса, потому что правильный идентификатор сеанса спускается.

Итак, я считаю, что IIS7 использует что-то помимо идентификатора сеанса в URL-адресе для определения уникального клиента. Возможно, что-то на уровне TCP/IP? Вместо уровня приложения (http). Это на ходу? Кто-нибудь знает ответ на этот вопрос?

К сожалению, не имея возможности воссоздать этот сценарий локально, я тяжело ломаю голову.

ответ

0

Вход Запрос Url, SessionId и IsNewSesssion .... что должен сказать вам, где проблема.

Сомневаюсь, что вы увидите действительную сессию, представленную в Url, но не отраженную в SessionId. Если вы видите, что значение, которое вы ожидаете, отражено в SessionId, но IsNewSession является истинным для нескольких запросов, это проблема с возвратом приложения.

+0

Я не верю, что это проблема с перезагрузкой приложения, потому что сайт работает так, как ожидалось, когда не использует прокси-сервер, или при запуске через несколько открытых прокси, которые я нашел в Интернете. Только когда у нашего клиента есть свой корпоративный прокси-сервер в середине. – 2010-12-01 22:24:28