Предложения по обработке статического ответа с динамическими данными сеанса
Представьте себе веб-сайт с высоким уровнем кэширования, в котором выходные данные почти каждого действия 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-запрос. Минусы = Кэширование становится сложным при использовании прокси-сервера динамического контента, может потребоваться поиск по длине контента и его замена на добавление дополнительных данных, может не работает с некоторыми браузерами?
3) Использование Comet для данных сеанса. Постоянное обратное кометное соединение AJAX может быть установлено в начале соединения с веб-сайтом. Тогда ко всем статическим HTML-запросам можно было бы обращаться нормально. Все связанные с сеансом запросы могут быть доступны из кометного соединения.
Плюсы = Разделение статического контента и динамического контента. Минусы = Comet не поддерживается очень хорошо и работает не очень хорошо, задержка сервера может конфликтовать с той же политикой происхождения.
Как вы, ребята, думаете, что эта проблема должна быть решена? Как вы думаете, это выполнимо?
1 ответ
Решение, которое я нашел, состоит в том, чтобы использовать шаблонные данные и динамические данные отдельно друг от друга. Это слишком много работы и слишком грязно, чтобы реализовать это самостоятельно, так что вы можете зайти так далеко, как использовать инфраструктуру MVC для предоставления JSON-запросов с шаблонами (AngularJS, KnockoutJS, EmbedJS и т. Д.), Или вы можете просто использовать шаблоны в общем. Имейте в виду, что это разрушает SEO.