Представьте себе веб-сайт с высоким уровнем кэширования, в котором выходные данные почти каждого действия GET кэшируются в HTML-файл, который доступен непосредственно с HTTP-сервера без необходимости выполнения операции CGI на стороне сервера.Теперь представьте, что в дополнение к этому JavaScript используется для фильтрации ответа на HTML-запрос с использованием AJAX.Ответ AJAX содержит только соответствующий ответ страницы (поэтому для стандартных HTML-страниц он будет содержать все, кроме окружающего макета, для модальных он будет содержать только модальное поле HTML и т. Д.).
Теперь давайте представим, что содержимое HTML может быть кэшировано нейтрально (когда никто не вошел в систему) или кэшировано для того, кто вошел в систему. Существуют определенные области страницы, которые связаны с данными сеанса (например, приветственное сообщение, ссылка профиля,и т.д ...) и эти данные являются специфическими для сессии.Но так как мы используем JavaScript, мы можем буферизовать ответ AJAX, изменить значения элемента сеанса, а затем вставить его в DOM, пока пользователь не знает о горячей замене сеанса.Это зависит только от грубых запросов GET и страниц, где фактическое содержание не зависит от сеанса на 100%.
Теперь вот мой вопрос.Если бы я должен был реализовать это (и поверьте мне, я буду), то как я мог бы фактически отслеживать активность сеанса, пока пользователь просматривает страницу?При традиционной операции на стороне сервера каждый раз, когда пользователь обращается к странице, инфраструктура на стороне сервера будет обновлять сеанс и следить за переменными, связанными с сеансом.При статической операции HTTP-запроса исключается любое участие на стороне сервера.Поэтому мне нужно найти способ отслеживать, что происходит с сессией;Вот мои подходы:
1) Выполните два AJAX-запроса (или дополнительный при необходимости): Как только пользователь запросит страницу, содержимое будет загружено в виде статического HTML.Но в то же самое время эта страница запрашивается, тогда другой AJAX-запрос будет обслуживаться для конкретного URL-адреса сеанса / сервера, обновляющего / запрашивающего состояние сеанса.Это может быть сделано бок о бок или может быть выполнено после каждых нескольких запросов.
Плюсы = HTML-файлы остаются без изменений, HTML-файлы могут иметь ETag или будущий заголовок expires, JavaScript может кэшировать толькостатический HTML и использование его для просмотра в автономном режиме, сеансовый сервер может быть выделен, оптимизирован и настроен для активности сеанса.Минусы = два AJAX-запроса выполнены, чрезмерный опрос для потенциально избыточных данных, обработка сеанса сделана отделенной от сервера контента.
2) Используйте промежуточный прокси, который добавляет данные сеанса в качестве завершающего сеанса JSON На сервер сделан запрос.Между ними находится прокси, который локально обращается к данным сеанса, а затем выполняет другой HTTP-запрос (локально или удаленно), который затем объединяется с данными сеанса, полученными непосредственно перед этим.Браузер отвечает чистой копией HTML-кода, в котором содержится специфичное для JavaScript содержимое сеанса, а затем все обновляется в одно и то же время.
Плюсы = Все загружается одновременно, требуется только одно подключение, работает какнормальный HTTP-запрос. Cons = Кэширование становится сложным, когда используется прокси-сервер динамического содержимого, может потребоваться поиск и изменение длины содержимого для добавления дополнительных данных, может не работать с некоторыми браузерами?
3) Используйте Comet для данных сеанса В начале соединения с веб-сайтом может быть установлено постоянное кометное соединение обратного AJAX.Тогда ко всем статическим HTML-запросам можно было бы обращаться нормально.Все связанные с сеансом запросы могут быть доступны из кометного соединения.
Pros = Разделение статического контента и динамического контента.Минусы = Комета не очень хорошо поддерживается и не очень хорошо работает, задержка сервера может конфликтовать с той же политикой происхождения.
Как вы думаете, ребята, эту проблему нужно решить?Как вы думаете, это выполнимо?