Оказывается, проблема давняя: 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.

Обнаружил только что, что HandyCache идёт ещё дальше вразрез со стандартами, он настаивает на включении заголовка `Transfer-Encoding: chunked` для запросов версии 1.0, хотя только версия 1.1 протокола HTTP описывает его и указывает, что любой клиент, использующий эту версию, ОБЯЗАН поддерживать данный метод передачи (то бишь по частям).