Дополнение: ответ от автора. Не баг, просто надо отключить "Кэш DNS" в HandyCache, и тогда разрешение имен будет выполняться через системные серверы.

Попробовал расширение, результат: при наличии в браузере расширений, добавляющих скрипты на страницу - поведение страниц может сломаться (зависит от страницы).
GitHub сломан напрочь, в консоли жалобы "None of the “sha512” hashes in the integrity attribute match the content of the subresource"
У меня, может, не самая стандартная инсталляция с моими цепочками прокси, но для меня оно не работает.
Мой вариант - во вложении.

Здравствуйте! качал дистр,закончился пакет трафика,мб 400 не хватило. Короче недокачал и файл исчез толи в хкэш, толи в кэш мозилы. Можно ли, и как, достать из кэша файл?

Оказывается, проблема давняя: http://handycache.ru/component/option,com_smf/Itemid,10/topic,7366.msg48098. Я просто не могу понять, почему вообще HC делает это, причём я не могу установить закономерность, по которой это происходит. Это приводит к серьёзной деградации производительности, в частности при отсутствующей информации о длине тела ответа многие приложения не могут использовать многопоточную закачку, а также похоже, что сама по себе данная кодировка работает медленней, так как я замерил закачку ресурсов через HC с данным заголовком, добавленным им самим, и тех, что были избавлены от данного проклятия, даже будучи большего размера, закачиваются гораздо быстрее.

Невозможно восстановить размер тела, если HC удалит соотв. заголовок из-за сложностей обработки `Accept-Encoding`, `Transfer-Encoding` и `Content-Encoding`. Также HC допускает ошибку, если попытаться указать самому в расширении `Transfer-Encoding`, HC создаст ещё один такой заголовок для кодировки `chunked`, насколько мне известно, данный заголовок может быть в единственном экземпляре и не более, а значения, если их более 1-го, должны разделяться запятой с пробелом. В частности, я не могу найти способ восстановить размер сжатого (`gzip`) ресурса при выдаче из кэша, так как в обработчик события `BeforeAnswerHeaderSend` -- последний момент, когда ещё можно изменить заголовки -- приходит размер сжатого ресурса, и при выдаче его клиенту, не ожидающему сжатие `gzip`, он, разумеется, не сможет принять такой ответ.

Прошу дать возможность так или иначе отключить или обойти данное поведение HC.

It's a pity this topic has been ignored because I also suffer from this oddity. Why would HC out of the blue do this? It's clearly inferior behavior if the content length is known beforehand (and it's known when cache is used). And if my extension explicitly sets `Transfer-Encoding` HC has no business changing it IMHO.

Михаил
Протестировал. Работает. 

Попробуйте изменить правило так:

С недавнего времени почему-то не всегда срабатывает на сайте. Это оборачивается тем, что рекламные объявы с такой меткой видны


или артефакты остаются



Т.е. резка вроде бы работает, но чаще всего не до конца. Проявляется в разных браузерах. (FF старый, новый; Chrome). Можно что-то с этим сделать?
P.S. Саппорт сайта подтвердил, что были какие-то изменения у них с этими рекламными блоками.

Спасибо за проверку. Глюк какой-то был. Сейчас норм.

"Fail to download..." - это информационное сообщение. Вижу, что малопонятное, но на общую работоспособность СМ оно влиять не должно.
Давайте попробуем разобраться с неработой СМ, а потом вернемся к сообщению.
Киньте мне почтой:
- файл Content_Master.ini из папки СМ
- файл HandyCache.ini из папки НС
- лог НС начиная от загрузки СМ и до неудачной попытки вызова настроек СМ