Инвалидация кеша при обновлениях на сервере

[sergey-s-betke]

Важный момент - http://tools.ietf.org/html/rfc7234#section-4.4. При запросах POST, DELETE и так далее (а это - и комментарии, и прочие вещи) необходимо генерировать заголовки Location и Content-Location в ответах на эти запросы с тем, чтобы сбросить кеш по указанным uri!

На эти правила крайне важно обратить внимание при обработке комментирования, публикации / удалении статей и так далее.

[sergey-s-betke]

• Content-Location - http://tools.ietf.org/html/rfc2616#section-14.14
• Location - http://tools.ietf.org/html/rfc2616#section-14.30

Location в плагине обрабатывать смысла нет. Он используется при перенаправлениях, по сути. А вот Content-Location (http://tools.ietf.org/html/rfc2616#section-13.10) следует использовать при ответе на глаголы PUT, DELETE, POST для указания URI содержимого, которое больше не является валидным.

[sergey-s-betke]

Идея хороша. По крайней мере, для кэша ARR подобные механизмы следует реализовать и использовать!

[sergey-s-betke]

Не вижу, чтобы Content-Location использовался Wordpress. Хотя RFC утверждает, что в том случае, если с запрашиваемым ресурсом связано несколько различных ресурсов, сервер должен указывать uri ресурсов, связанных с ответом, в своём ответе в заголовке Content-Location.

[sergey-s-betke]

http://www.subbu.org/blog/2008/10/location-vs-content-location

[sergey-s-betke]

В общем и целом - разобрался в вопросе. Location - не наш случай (используется только для перенаправления). А вот Content-Location - вполне. Но! - это всего лишь альтернатива "canonical link", не более. К сожалению. Указать несколько url в Content-Location в POST - пока не уверен, что можно будет, и не уверен, поймут ли прокси серверы несколько заголовков в одном ответе.

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

[sergey-s-betke]

google так же не нашёл идеального решения по этому вопросу. Предлагают изменять url, что гарантирует повторный запрос через все уровни кэша.

[sergey-s-betke]

Учитывая планируемое использование AJAX, идея следующая. Время жизни групповых url (типа - главной страницы ленты блога и так далее) придётся делать минимальным. Но грузить контент в такие страницы предлагаю иначе.

При запросе при доступном механизме ajax имеет смысл либо использовать дополнительные заголовки с Vary, что несовместимо с некоторыми реализациями кэша, либо же менять uri (например - добавлять параметр ?ajax=true). Время жизни подобных url в кэше можно сделать существенным, потому как собственно данных они содержать не будут. AJAX движок темы будет запрашивать JSON список содержимого страницы, и, далее, представление каждой статьи будет так же запрашивать отдельно!

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

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

[sergey-s-betke]

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

Как вариант, предлагаю формировать autoload опцию в WordPress либо с последней датой обновления, либо с последним ETag. Опцию - потому, что она они и так будут загружены при обработке запроса, и других запросов можно попробовать избежать в этом случае. Но такой механизм касается только проверки актуальности списков статей и прочих сущностей в WordPress.

[sergey-s-betke]

На таком решении и остановимся:

• инвалидацию кэша статей и прочих сущностей - через изменение url, время жизни максимальное
• инвалидацию кэша списков сущностей - через минимальное время жизни в кэше, и через дополнительный механизм поддержки If-Modified для генерации ответов на запросы списков
• также после выполнения действий, подразумевающих изменение списка сущностей целесообразно заставить движок темы запросить список по уникальному url (со специальным параметром с уникальным значением), что в любом случае приведёт к инвалидации кэша.

P.S. при ajax ответах формировать Content-Location необходимо. Это позволит, в частности, провести инвалидацию и "базового" url кэша списка сущностей при принудительном его обновлении через запрос уникального url.

[sergey-s-betke]

Итого, в этом плагине помочь этому вопросу нечем.