Предлагаю подумать над возможностью кэшировать не только благополучные исходы (типа 200), но и некоторые негативные (типа 404). 404, например, каждый раз будет иметь место, если на любимом сайте нет favicon.ico, а браузер каждый раз его запрашивает. Либо какая-то ссылка на странице устарела.

---

  Реализовано с версии HC 1.0 RC1 с помощью скриптов Lua !

Можно держать их в индексе. Так же как и ответы 301, 302. Кстати, для последних, на мой взгляд, тоже нужно свое TTL, не ассоциированное как сейчас со списками "Т" и "Н".

Можно и в том же индексе. В индекс добавится только байт кода ответа. Не надо будет зато создавать отдельную структуру. Индекс по мере ненадобности будет выгружаться из памяти (а точнее замещаться другими). Еще удобство: грузится индекс - автоматом грузится метаинформация о всех файлах сайта, в т.ч. и об отсутствующих/перемещенных. И когда браузер тупо попросит favicon.ico, никуда дополнительно лезть уже не надо. И специальных файлов на диске создаваться (как сейчас для ответов 301 и 302 с окончанием #m в расширении) не требуется.
Кстати, ответь, плиз, если знаешь: программистская работа над внедрением индексов ведется, или эта идея существует пока на уровне наших обсуждений на форуме и неочевидно, будет ли вообще реализовываться?

Вообще говоря ответы 4** - с передачей файла.
А на некоторых сайтах даже контент с таким кодом передаётся (с целью недопущения его сохранения)

Да, бывает и такое, но в большинстве случаев "404" используется по своему прямому назначению и вместе с ним передается информация типа: "Нет такой страницы", не имеющая для нас практической значимости! Следовательно, и сохранять ее не обязательно - достаточно сохранить сам факт отрицательного ответа, чтобы повторно не обращаться к серверу какое-то время!

Можешь привести реальные URL, где "404" используется для передачи "полезного" контента с целью недопущения его сохранения?
Как HC будет отличать "полезный" контент от "бесполезного"?

---

Спроси у mai62...

Вот здесь набрел на пример. Вместе с "404 Not Found" качается 114x2=228 кБ!!! данных. Полезность их оценить не могу, но судя по названию файла и тайному способу его закачки, подозреваю только вредность.

Они ("мелкие картинки") и есть. На самом деле это html-файл размером ~114 КБ.

Хранить - и так понятно. Тут качать тело неизмеримо вреднее! Придется правило в Черный список писать. Неплохо бы знать, много ли таких фокусов в сети? Ежели так, то имеет смысл увидев "404" останавливать закачку.

PS Зашел на тот же адрес через другого провайдера - результат тот же: файл 1x1.gif занимает 114 кБ.

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

Опытным путем обнаружил, что главная страница thg.ru на "404" всегда грузится только в Опере, а в Макстоне (IE) такой проблемы нет!
P.S. Вот поэтому я и не люблю Оперу... 

Есть обратное предложение - НЕ кешировать ответ 302.
Ибо некоторые ресурсы (например, livejournal) балуются интересной формой отдачи страничек через два редиректа с возвратом к исходному... в результате при кешировании редиректа все зацикливается.

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

Циклится из-за списка "Не обновлять"? Какие правила срабатывают при зацикливании?

Приложи лог HC с отладочной информацией.

М-да, есть цикл. При запросе http://users.livejournal.com/_n1ke_/friends HC вставляет в запрос заголовок "If-Modified-Since", в ответ на который сервер сайта велит брать файл из кэша!

Что можно сделать:
- Либо запретить кэшировать URL вида: users.livejournal.com/*/friends
- Либо в настройках HC "Общие / Управление загрузкой" отключить опцию "Добавить If-Modified-Since при наличии файла в кэше"

---

mai62

Видимо, не стоит HC в "If-Modified-Since" вставлять дату файла #m !
Он же не содержит тело самого файла, а только заголовки с переадресацией!

Без кэширования редиректов HC не сможет найти в кэше в автономном режиме некоторые страницы (файлы), т.к. информации о их новом местоположении он не сохранил!

Кэширование редиректов в HC появилось не сразу, а потому что об этом многие просили на ру-борде!

DenZzz
еще можно всегда обновлять редиректы (весят они мало)
+ из кеша брать более свежий файл (если имеются одновременно редирект и данные)

Зря забыли эту тему! Еще один пример:


По статистике загрузок http://savepic.ru/ можно сделать вывод, что сервис довольно популярен! Но из-за того, что HC не умеет кэшировать 404 приходится грузить эти картинки вновь и вновь при каждом обновлении страницы!

Хочу добавить, что на некоторых серверах только в виде ответов "430 Forbidden" и можно получить полезное содержимое! Пример - по этой ссылке можно просмотреть первую страницу статьи (и она находится Google'ом!), но приходит страница в виде "430 Forbidden".
Такие страницы не кэшируются. Однако в данном конкретном случае это следовало бы делать!

Похоже, что следует исходить из принципа: всё, что не запрещено - разрешено! К сожалению, некторые сайты (как раз те, которые и следовало бы кэшировать, т.к. их внутренняя статистика посещений преследует цель отнюдь не облегчить жизнь человеку - а скорее при избыточном интересе к статье с данного IP перекрыть к ней доступ вообще!) готовы использовать этот принцип на все 100! Этот пример наглядно демонстрирует, насколько важно кэширование нестандантных ответов тапа 403, якобы Forbidden (а на самом деле вовсе не Forbidden, а реальная ценная информация!).