last-modified + MS2

Хотел сегодня с помощью плагина, настроить отдачу заголовка last-modified.
И получил глюк корзины. То товары добавляются, то нет, то удалить нельзя из корзины.
Ошибок в журнале нету, все запросы типа проходят, но ничего не меняется.
Куда копать?
Плагин работает по событию:
OnLoadWebDocument
Вот код плагина:
<?php
if($modx->event->name!='OnLoadWebDocument') return;
if(!empty($_SERVER['HTTP_IF_MODIFIED_SINCE'])){
$lastMod = strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']);
if($modx->resource->editedon <= $lastMod){
header("HTTP/1.0 304 Not Modified");
header("Cache-control: private, max-age = 3600");
header('Expires: '.gmdate('D, d M Y H:i:s', time()+3600));
exit();
}
}
header("Cache-control: private, max-age = 3600");
header('Expires: '.gmdate('D, d M Y H:i:s', time()+3600));
header("Last-Modified: " . gmdate('D, d M Y H:i:s', $modx->resource->editedon) . " GMT");
return;
Владимир Колесник
Владимир Колесник
26 марта 2013, 13:42
modx.pro
1
4 514
0

Комментарии: 15

Алексей Карташов
Алексей Карташов
26 марта 2013, 20:58
0
Пока искал ответ на ваш вопрос, натолкнулся на занятную статью, в которой есть отсылка на сервис для проверки правильности отдачи этих заголовков.
Так же, на этом сервисе есть 2 занятные статьи, после прочтения которых, вывод (относительно MODx) не такой уж и однозначный…

Дело в том, что у вас идёт проверка на последнее изменение КОНТЕНТА страницы, т.е. последнее сохранение ресурса.
И, если 
$modx->resource->editedon <= $lastMod
дата последнего Last-modified, который запомнил клиент (браузер или робот поисковика) больше (или равна) дате последнего сохранения ресурса в modx, то вы отдаёте 304 и клиент эту страницу загружать уже НЕ БУДЕТ.

Но вот нюансы:
— если вы добавили новый ресурс, который должен быть виден в меню;
— или у вас появился новый комментарий к статье;
— или у вас стоит какой-нибудь модуль финансовых сводок, который должен отображать актуальную информацию;
— да мало ли что ещё…
то пользователь этих изменений уже не увидит! Потому что он будет брать эту страницу из своего кэша.

ИМХО вопрос с Last-Modified нужно продумывать ГОРАЗДО тщательнее и на каждом конкретном сайте в индивидуальном порядке. И простым плагином здесь уже не обойтись.
Всё зависит от (кхм) зависимостей данных, отображаемых на текущей странице, от данных на других страницах (к примеру вывод новостей) или сниппетов и модулей (к примеру галереи или комментарии).

Вот такие пироги. Решайте — выбирать вам.
    Василий Наумкин
    Василий Наумкин
    26 марта 2013, 21:04
    0
    Полностью согласен.

    В MODX это просто не имеет перспектив, если только не прописывать работу с заголовками каждому используемому сниппету.
      Алексей Карташов
      Алексей Карташов
      26 марта 2013, 22:02
      0
      > если только не прописывать работу с заголовками каждому используемому сниппету.
      Именно. Но это такое не благодарное дело получится.
      Но если уж заморачиваться, то логика должна быть примерно такой:
      КАЖДЫЙ сниппет при КАЖДОМ своём выводе должен сверять ПРЕДЫДУЩУЮ выводимую им информацию с ТЕКУЩЕЙ выводимой им информацией. Т.е. надо завести отдельную таблицу и хранить там, к примеру, md5 от выводимых сниппетом данных и дату этих данных. И если md5 от текущих данных отличается от md5 из таблицы, то перезаписывать md5 и дату.
      Потом на то же событие «OnLoadWebDocument» проверять количество сниппетов, в которых данные изменились с последнего вызова (эту переменную можно держать в сессии и каждый сниппет при необходимости инкрементирует её). И если это количество отлично от нуля, то отдавать 200. Иначе отдавать 304 (естесственно, не забыть проверять и дату последнего редактирования ресурса, как в текущем варианте).

      НО:
      1. Мы здесь теряем одно преимущество этого заголовка — снижение реальной нагрузки на сервер (это при достаточно годной посещаемости). Ведь фактически нагрузка увеличится! Это +1 запрос к вызову каждого сниппета и, если использовать md5, то ещё и на хэширование ресурсы тратить.
      2. Как определить уникальность вызова сниппета и однозначно идентифицировать его в нашей специальной таблице?

      В принципе, можно написать сниппет-обёртку (как getPage), который будет делать всю эту грязную работу. Ну и плагин доработать слегка.
      Для поисковиков будет хорошо, да. Эту задачу этот сниппет+плагин будет решать.

      Но со вторым «НО» из списка выше пока не понятно. Да и популярностью данное решение пользоваться не будет — оно сложно для понимания и оборачивать нужно КАЖДЫЙ вызов КАЖДОГО сниппета, что, естесственно, подавляющее большинство делать не будет.

      Да и кому это вообще надо-то?))) Нафига я всё это писал? xDD
        Алексей Карташов
        Алексей Карташов
        26 марта 2013, 22:09
        0
        Кстати, по 2му пункту — можно брать хэш от имени сниппета и строковых представлений имён параметров и их значений (предварительно отсортировав имена параметров по имени, например). Тогда да — мы будем однозначно идентифицировать каждый вызов каждого сниппета. Но ИМХО — это ещё одна совершенно лишняя нагрузка. Хотя идея рабочая.
    Василий Наумкин
    Василий Наумкин
    26 марта 2013, 21:06
    0
    Глюк корзины может быть только от глюка сессии.

    А глюк сессии может быть либо от php-apc, либо оттого, что браузер ориентируясь на заголовки что-то не грузит.

    Я одно время интересовался этой темой и пришел к выводу, что она не перспективна. Время и силы лучше потратить на оптимизацию сервера и скриптов, чем на глючное кэширование.
      Алексей Карташов
      Алексей Карташов
      05 сентября 2013, 22:26
      0
      А я вот всё-таки сделал такой пакетик. Работающий правильно и не требующих никаких танцев с бубнами.
      Решил его сделать платным (но не дорогим), потому что только истинные оптимизаторы понимают ценность такой вещи.
      Написал в SimpleDream с предложением добавить его в репозиторий, но они ничего не ответили…
      Павел Левин
      Павел Левин
      25 марта 2015, 16:35
      0
      Ну как? Тема затухла?
      Есть толк от 304?
      С точки зрения логики, то штука полезная по идее новые страницы будут отдаваться в поиск быстрее (сейчас яндекс может задерживать аж на 2 недели и более).
      Просветов Игорь
      Просветов Игорь
      11 апреля 2015, 20:23
      +1
      Поддерживаю, толк есть.
      Поисковый робот ограничен количеством запрашиваемых документов за один обход согласно выделенной квоте. И для больших сайтов эта очень полезная штука.
      Алексей может поделитесь с народом?
      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
      15