Last-Modified: - какую дату ставить? И нужно ли оно вообще?

нужно ли оно вообще? Вообще да - https://yandex.ru/support/webmaster/robot-workings/robot-workings-faq.xml#no-last-modified .

Для себя вопрос решил так:

-Создается файловый кэш

-При запросе проверяется время файла кэша (filemtime)

-Отдаем или нет 304

Если изменится ,скажем ,меню - изменится файл кэша,а с ним и время модификации файла.

Eteg от хэша HTML документа - очень интересно.. в чем логика такого Etega?

У вас получается, что скрипт прошел весь цикл(запросы к БД, сборка шаблона) и только на финальной стадии перед отдачей клиенту заголовков и контента скрипт сверяет if-none-match хеша уже готового к отдаче контента.

Тоесть скрипт нигде не прервался к примеру после запроса к БД где у вас есть временная метка и вы можите сравнить по if-modified-since отдать 304 ответ и прервать скрипт. Для чего и нужен last-modified.

А вся эта обвеска виджетов, меню и прочего - все это на мой взгляд параллельно.. есть основной контент: статья ну и к примеру дата последнего комментария к этой статье.

Ну а страницы на которых контент очень часто обновляется, тогда лече вообще не отдавать никаких заголовков.

Спасибо, покурю.

Ну это близко к тому что я предложил в четвертом варианте. Только здесь плотная интеграция с кешированием. Это несколько уменьшает гибкость схем кеширования, инвалидацию этого самого кеша и т.п. А там нюансов полным-полно.

Для единичных проектов это еще можно допустить и отслеживать весь стек кеширования, но для универсальных решений - не очень.

В реальных задачах это самое "прервался" становится очень нетривиальным.

Запрос в базу по основному контенту нам полюбому делать ибо нам нужна дата.

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

Аналогично различные блоки в сайдбаре, а то и весь сайдбар целиком.

В целом при грамотном кешировании частей - где результат рендеринга, где только данные - всё умеренно легко выходит.

Общий контент страницы кешируем по небольшому TTL. В хайлоаде кеш "нагреется" быстро, и очищаться будет не часто, а при низкой нагрузке сильно кешировать и не обязательно.

Зачем отдавать при полном перерасчете? Трафик, скорость рендеринга страницы в браузере - это тоже существенно. Особенно для мобильных браузеров и для пауков поисковиков.

Ну вот примерно об этом и вопрос был изначально. Но тут мы говорим о мнениях, а не опыте или анализе.

---------- Добавлено 21.10.2016 в 14:46 ----------

Многабукафф написал, а основное не сказал.

Почему вообще рассматриваю хеш от всего контента? Больше всего меня смущает то что могут меняться ЗНАЧАЩИЕ данные в совершенно не связанных со страницей местах, и их придется отслеживать вручную. Два примера:

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

При этом данные редактируются в базовых настройках сайта ибо могут использоваться и в других страницах (например контакты в футере или шапке).

В таймштампе основного контента это изменение не отразится. Нужно отслеживать вручную в контроллере. Лишняя возможность выстрелить себе в ногу.

2 - в другом проекте у меня есть "хеш-вставки". Это отдельная табличка у которой есть некий текстовый ид и текстовое поле (цк-едитор) в котором редактируется содержимое. А в значащих полях вроде основной статьи страницы можно вставлять специальные коды с этими ИД, и при выводе статьи везде где есть этот код будет вставлен нужный контент. Потом его поменяли в одном месте - и везде поменялось. Например телефоны менеджеров в описании товара и т.п.

Но наша статья "не знает" что ее содержимое поменялось, а наш хеш-инсерт "не знает" где его вставляли, чтобы обновить чужие тайминги.

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

В общем задач может быть много, и "хеш всего" это оптимальный вариант.

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

Ну, я так понял, что речь идет о "статейном" движке, где это даже очень тривиально(у самого такие поделки есть, где изначально приложение проектировалось с учетом этих заголовков).

Может вам будет интересно..

Хранить хеши УРЛ и ЕТАГ в сериализованном массиве в неком файле. На точке входа сверять эти хеши, что делать..(отдать 304 ответ) а на выходе писать новый хеш ЕТАГ если не совпадает с If-None-Natch.

MVC.

ActiveRecord. Естественно связи моделей, валидация и т.п.

ActiveForm, виджеты пагинации, сортировки, поиска, префильтров, всяких бутстраповых виджетов и т.п.

RBAC пока дописываю но в целом есть,

Вызов апи движка из командной строки (Т.е. cron и всякие чятики на вебсокетах вполне себе работают в рамках АПИ движка, с роутами ведущими в обычные контроллеры и т.п.

генерация админки из конфигов (собственно всё из конфигов), т.е. пару строк на CRUD с кучей вариаций.

Миграции, точнее что-то похожее - в зачаточном состоянии, но есть.

Два десятка готовых типовых контроллеров для множества задач. Но буду сокращать объединяя похожие.

16 вариантов цветовых схем и т.п., 12 различных параметров настройки структуры шаблона.

Ну и по мелочи корзина там, каталог товаров, отправка писем с шаблонами и т.п.

Всё это несколько больше чем "просто статейник")

Называю это CMS а не фреймворком потому что документации полноценной нет, АПИ меняю за месяц очень сильно, так что готов пока поддерживать только функционал чисто CMS с возможным полным изменением всего кода в любой момент при обновлении. Ну и пока сыро я бы не хотел слишком много людей пускать "под капот". Недавно вон нашел XSRF у себя, в ядре для POST убивается всё что не подписано маркером, а вот через GET в нескольких местах умудрился таки отправлять команды на изменение...

Да, это не CMS а полноценный фреймворк и тем более не "просто статейник"..

Если бы вы перечислили весь этот "функционал" вашей "CMS" в старт-посте - я бы просто прошел мимо.. побоялся бы, чтото писать а тем более советовать :)

Ну тема то в сеошном разделе а не вебмастерском, так что обсуждения в любом случае в тему.

Да и по факту оно сейчас деградировано до ЦМС, много чего еще не дописано.

Но вынужден все делать с оглядкой на то что фреймворк станет полноценным а значит DRY.

Сейчас еще одна мысль появилась.

Если этот параметр влияет на дату документа в поиске, то может просто его отдавать, но 304 не выдавать даже при совпадении, а 304 только по етаг?

Хотелось бы статистику по тому какие юзерагенты умеют ласт-модифай но не умеют етаг, и их долю.

HTTP протокол никак не ограничивает.

Зачем эта статистика? Все популярные десктоп/мобайл браузеры понимают все кэшируюшие заголовки, и этого достаточно. Если уж не понимают, они же серавно получат документ.

Что касается основных ПС, давненько я читал статейку(уж не припомню где) автор которой анализировал логи и пришел к выводу, что If-None-Match отправляет только бот Бинга а Гугл и Яндекс - нет. А If-Modified-Since отправляют все трое. Есть недавняя статистка по Гуглу и Яндексу.

Ставить дату последнего изменения документа

Даже так? Надо будет проверить. Важное замечание, спасибо.

Вы из Питера? Случаем не моряк?)