Обработка файлов cookie в последующих запросах на той же странице - PullRequest
0 голосов
/ 20 февраля 2012

Я создаю свой собственный (многопоточный) ISAPI-сайт на C ++ и пытаюсь реализовать правильное управление сессиями.

Проблема в том, что при создании нового сеанса сеанс создается дважды при использовании последующих запросов на сгенерированной веб-странице.

Вот как это работает: - Клиент запрашивает http://localhost и не отправляет ни cookie, ни cookie со старым идентификатором сессии. - Сервер просматривает файл cookie сеанса и чувствует, что ему нужно создать новый файл, потому что он больше не существует: он готовит заголовок с файлом cookie с новым идентификатором сеанса и отправляет полный заголовок клиенту (я отслеживал это с http live заголовки плагина в firefox и это правильно). Он также подготавливает некоторые данные, такие как страница, и тому подобное (еще не данные тела, поскольку он все еще обрабатывает данные из базы данных и тому подобное) и отправляет то, что у него есть, обратно клиенту. - Клиент должен иметь этот новый сеансовый cookie сейчас, и видит ссылку на таблицу стилей и немедленно отправляет запрос таблицы стилей http://localhost/css на мой сервер. Но ... он все еще делает это со старым идентификатором сеанса по какой-то причине, а не с недавно полученным! - Сервер видит этот запрос (снова с уже не существующим идентификатором сеанса), генерирует другой новый сеанс и отправляет новый идентификатор сеанса вместе с файлом cookie вместе с данными таблицы стилей.

Таким образом, клиент получил два идентификатора сеанса сейчас и с этого момента будет продолжать использовать второй, так как первый перезаписывается, но, тем не менее, первая страница использовала неправильный сеанс (или фактически, вторая страница имеет).

Можно сказать, что это не проблема, но когда я начну использовать персонализированные таблицы стилей, у меня будет неправильная таблица стилей на первой странице, и поскольку страница будет использовать AJAX для обновления содержимого (если доступно), это возможно что таблица стилей никогда не перезагружается до тех пор, пока клиент не обновится.

Итак, это проблема, которая всегда возникает при выполнении подобных вещей? Будет ли браузер всегда отправлять старый cookie, хотя он уже получил новый, но все еще обрабатывает страницу? Это проблема, которая есть, например, в PHP?

Примечание: до того, как начнутся все дискуссии об «использовании php вместо» или о чем-то: я переписываю сайт, который я впервые написал на PHP, он стал популярным, имел тысячи (реальных) посетителей каждый час и начал убивать мой сервер (веб-сайт не приносит столько денег, сколько я могу использовать на нем много серверов). Написав это на C ++, запросы занимают 2 мс вместо 200 мс в PHP ... Я могу оптимизировать все. Потратив время на правильную разработку ISAPI, он безопасно многопоточный и может быть многопроцессорным, многообслуживаемым. И больше всего мне нравится этот вызов.

Добавлено примечание. Кажется, что проблема возникает только тогда, когда в файлах cookie существует старый сеанс, потому что, когда я полностью удаляю все файлы cookie из своего браузера, а новый создается и отправляется обратно клиенту, последующая таблица стилей Запрос немедленно использует данный идентификатор сеанса. Кажется, это своего рода доказательство того, что я делаю что-то не так при отправке старого идентификатора сеанса ... Следует ли сначала удалить существующий файл cookie? Как?

Добавлено примечание: cookie записывается с датой истечения на год вперед.

1 Ответ

0 голосов
/ 21 февраля 2012

Я выяснил, в чем проблема, я исходил из того, что установка cookie без указания пути приведет к тому, что сессия будет работать на всех путях в этом домене. Используя http://foo.bar/home в качестве главной страницы и http://foo.bar/home/css в качестве таблицы стилей, внутренне переводя этот URL-адрес в? S1 = home и? S1 = home & css = y, я фактически использовал два разных пути в зависимости от браузера, который не передал куки в css-запрос.

Почему-то они на самом деле собрались потом, я не до конца понимаю, почему.

Разве это не глупо? Будут ли люди редко иметь http://foo.bar/index.php и http://foo.bar/css/style.css.php только потому, что они используют подкаталоги для поддержания своей структуры в чистоте?

Если кто-нибудь знает, как это исправить, чтобы подпути также работали с теми же файлами cookie, дайте мне знать, но, как я понимаю из определения файлов cookie, они застряли в определенном пути (хотя, похоже, что, если вы специально добавите путь, отличный от /, он будет работать и в подкаталогах?)

...