2012-02-20 7 views
0

Я создаю свой собственный (многопоточный) сайт на базе ISAPI на C++, и я пытаюсь реализовать правильное управление сеансом.Обработка файлов cookie в последующих запросах на одной странице

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

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

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

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

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

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

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

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

+0

У меня есть ответ ... Я отправлю его, когда глупый 8-часовой предел для ответа на вопрос закончен. – scippie

ответ

0

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

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

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

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

 Смежные вопросы

  • Нет связанных вопросов^_^