DenzZzz
Раз уж встал вопрос об учете при определении процента экономии оветов "304 Not Modified" на запрос "lf-Modified-Since" клиента, то расскажи, плиз, подробнее, как работает эта опция. Давно хотел вникнуть - но все забывал спросить (исходим из того, я читал краткое описание, т.е. общий принцип ясен).
Интересует, как учитываются критерии свежести, когда и как выдается из кэша более новый файл, если таковой есть.

Так что все-таки должно происходить, когда файла нет в кэше НС?

Добавлено: И еще вопрос. Если от клиента поступило If-Modified-Since и стоит опция "Добавлять IMS", изменяется ли в этом случае исходное IMS при пересылке запроса на сервер?

М-да... Неясно и так. Давай попробуем еще раз.
"Обычный" порядок (запрос от клиента без IMS): После проверки списка "Т" и отсутствия в нем файл проверяется на наличие его в кэше. Если есть - идет проверка списка "Н". Если нет в кэше - качаем из сети.
Если приходит запрос с IMS, этот порядок как-то меняется? Или что-то другое происходит, не пойму никак.

DenZzz
Теперь гораздо понятней.
Да... пожалуй, когда мы в такой ситуации отвечаем "304",  то при расчете процента экономии этих телодвижений учесть никак не удастся...
Только вот такой вопрос еще:
1. Если файл есть в кэше НС, не просрочен и IMS < Даты изменения этого файла, почему мы отвечаем "304", а не отдаем файл из кэша?
2. Если файла нет в кэше НС, почему в случае наличия правила без критерия свежести мы отвечаем "304", а не лезем в сеть?
По ходу пьесы получилось, что вопросЫ

Почему отвергаем вероятность противоположного исхода (у клиента старый и неактуальный файл)?

Пока еще не созрел до этого предложения... Но чем черт не шутит
Предлагаю отдавать файл в этом случае (если он есть в кэше НС, не просрочен и IMS < Даты изменения этого файла) из кэша НС.

Добавлено: чтоб браузер и дальше мог рационально вставлять IMS, можно выдачу этого файла из кэша сопроводить полем Last-Modified = Дата изменения файла. И подумать, мож это поле стоит втыкать вообще всегда, когда файл берется из кэша? Или оно и сейчас втыкается?

1. Мы ж и так парсим заголовок. Считать значение IMS легко в ходе этой процедуры.
2. Но это не главное. Главное - не допустить выдачу пользователю неактуального файла!

DenZzz
Молча выдать файл из кэша - гораздо быстрее и прозрачнее, чем озабочивать пользователя чисткой кэша браузера. Последнее к тому же:
  - заранее неизвестно, когда надо делать, чтоб не получить неактуальный файл;
  - сопряжено с дополнительной ненужной нагрузкой на пользователя.
С каких пор взятие из собственного кэша НС стало "побочным эффектом"?
Теперь представь ситуацию: два пользователя А и Б на одном кэше. У А правило в списке "Н" с критерием свежести, к примеру, 10 минут для новостного сайта. У Б такого правила нет. Оба пользуются сайтом регулярно. Пусть файл записался в кэш, и пошли эти самые 10 минут. После этого каждые 5 минут Б обращается к сайту, и файл в кэше обновляется. Чтоб проще было представить такую ситуацию, пусть пользователь Б не один, а их много. Тогда пользователь А НИКОГДА не дождется обновления файла, пока его клиент будет посылать IMS!
Такого допускать, на мой взгляд, нельзя.

DenZzz
"Частота" и "редкость" ситуаций будут плавать в зависимости от конкретной конфигурации/стиля серфинга.
К тому же зачем нам вообще неадекватная информация, пусть даже в редких случаях, не говоря уж о варианте частых?

Михаил
Я вообще критерием свежести не пользуюсь. В списке "Не обновлять" у меня только графика и др. оформление. Если надо обновить картинку, то просто держа горячую клавишу жму на "Загрузить изображение". Мне не хочется, чтобы незаблокированные банеры втихую обновлялись.