Начав разбираться с meta-данными, я столкнулся с проблемой кеширования. Согласно спецификации протола HTTP1.0 для управления кэшированием есть только зоголовок PRAGMA. если оный заголовок отсутствует, то клиенту позволяется кешировать html-код, пришедший от сервера. Если устанавливать заголовок PRAGMA, то только в значение no-cache, что значит "не кэшировать данный документ.
Протокол HTTP1.1 предоставляет более удобные инструменты для управления кэшированием. Там доступны два заголовка EXPIRES (Дата устаревания документа) и CACHE-CONTROL. CACHE-CONTROL может быть установлен в значения public (документ кэшируется в доступных для всех кэшах), private (только в частном кэше), no-cache (не может быть кэширован) и no-store (может быть кэширован, но не сохраняется).

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

но есть проблема - на какой протокол ориентироваться? писать везде no-cache и не беспокоиться ни о чем, или подойти к страницам дифференцированно? но тогда как указать дату устаревания для клиентов, не поддерживающих HTTP1.1? Сегодня все браузеры способны работать с версией 1.1, но вот, например, в настройках Internet Explorer по умолчанию не установлен флажок "использовать HTTP1.1 через прокси-соединения".  А очень много людей сидят в интернете из локальной сети через прокси. Еще больше подключенных без прокси, но и тех и других много, и угодить нужно всем. Как быть? что писать в заголовках ?

А кто запрещает использовать все заголовки? Если браузер встретит незнакомый заголовок, он его просто отбросит. Вставляй все заголовки.

А вот насчет дифференцированного подхода интереснее. Подумай над тем, сколько времени ты потратишь на реализацию и какова будет выгода. Встает вопрос, а так ли оно надо? IMHO, лучше такие вопросы оставлять серверу на усмотрение.

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

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

а про сложность - в движке, с которым я работаю можно, создавая класс новой страницы, одной строчкой переопределить один из мета-заголовков в базовом классе. итого на три заголовка - три строчки. не в сложности дело, а в правильности!

ну так что посоветуете еще ????

Я поступил слудующим образом.
Во-первых, на HTTP1.0 забил (всем во всём всё равно не угодишь).
Во вторых, использую Conditional GET. То есть, страница кэшируется браузером, но по критериям E-Tag и Last-Modified проверяется — а не пора бы обновить. А там уже сервер решает, что отправить — обновлённую страницу, или 304 Not Modified.

спасибо. изучим. а дополнительный функционал надо невешивать на апач? или как то настроить?

http://xpoint.ru/know-how/VebAlgoritmyi/Co...nalGet?comments


Это сообщение отредактировал(а) Porshen - 9.2.2007, 18:19

Да нет, у апача-то всё по умолчанию должно работать. Но это, естественно, тока для статичного контента.
А вот в скриптах логику «что отдать» — страничку, или код 304, придётся самому писать. Алгоритм такой: смотрим заголовки запроса (If-Modified-Since и If-None-Match). Если их нет, отдаем страницу безусловно. А если они есть, то решаем, будет ли сгенерированная страница им удовлетворять, или нет. Если нет, то отдаём её, уже с новыми E-Tag и Last-Modified. Ну а если да, то посылаем курить бамбук 304.

Это сообщение отредактировал(а) Greendrake - 9.2.2007, 22:20