Мое понимание жизненного цикла сеанса в Ruby on Rails (в частности, v3 и выше) состоит в том, что сеанс создается в начале запроса для каждого запроса, и если этот запрос не содержит существующий файл cookie сеансабудет создан новый, в противном случае файл cookie сеанса десериализуется и сохраняется в хэше сеанса.
Цель этого, конечно, поддерживает ряд функций безопасности, таких как CSRF и т. д.
Тем не менее, это создает некоторую проблему, когда речь идет о кэшировании страниц на сайте с помощью служб кэширования HTTP и прокси-серверов, таких как Varnish, так как большинство конфигураций имеют тенденцию удалять эти (как правило, все) файлы cookie как по запросу, так и по запросу.конец ответа (так как кеш обычно предназначен для обобщенной аудитории).
Я знаю, что можно настроить Varnish и т. д. для создания хэша объекта с включенными деталями cookie, и это позволит охватить кэшированные данныеэтот сеанс (и для этого пользователя), однако мне интересно, если этосовершенно необходимо.
У меня есть приложение, которое по своей природе довольно «статично» - контент извлекается из базы данных, отображается на странице, которая затем может быть кэширована - есть несколько элементов (таких как счетчик комментариев«последние» элементы и т. д.), которые могут быть добавлены с помощью ESI, но для каждого запроса Rails по-прежнему стремится установить новый сеанс, и, когда у пользователя уже есть сеанс, этот материал удаляется сервером кэша.
Мне интересно, возможно ли было бы (с помощью уже существующей функциональности или созданием этой функции самостоятельно) позволить разработчику контролировать, когда требуется сеанс, и только когда это задано, является задним числом?необходимо пересылать файлы cookie, инициализацию / десериализацию сеанса и т. д.
Это, или я думаю об этой проблеме неправильно, и необходимо решить проблему под другим углом ...