Согласен, надо как-нибудь добраться.

Чревато тем, что у клиента может оказаться часть совсем не того файла, что есть у нас в кэше, и склеив их, клиент получит все ту же абракадабру! Отдавая сейчас весь файл из кэша, HC это предотвращает!

Сейчас мы не храним ни ETag, ни истинный IMS файлов в кэше. Соответственно, сопоставить их с запросом клиента, мы не можем! Следовательно, никто не может гарантировать, что в кэше у нас лежит именно тот файл, часть которого запрашивает клиент!

Сравнивать IMS клиента с датой файла в кэше, конечно можно, но это крайне ненадежный способ идентификации неизменности файла, т.к. он зависит от точности системной даты и времени, от скорости канала и т.д. ...

Я не раз наблюдал в ReGet-е в процессе докачки на медленном канале сообщение типа: "Размер файла на сервере изменился! Удалить временный файл и начать закачку с начала?"
Причем, если жмешь "Нет", то он просто останавливает докачку!
А когда конечный размер файла неизвестен или не совпадает, то ReGet сразу трубит, что докачка невозможна и качает в 1 поток, а случае разрыва соединения предлагает начать все с начала! И это правильно!

Поэтому твой пример с багом выше вызывает у меня недоумения! Первая часть из кэша пришла с одним размером, вторая часть с сервера - с другим (без GZIP разница в разы, трудно не заметить)!
Какой менеджер закачек у тебя позволяет себе склеивать такой битый файл? ИМХО, это баг менеджера закачек!


P.S. Вообще-то, этой теме самое место в разделе "Новые предложения"! Вопрос о кэшировании/отдаче из кэша "206" уже много обсуждался в теме "Докачка файлов", куда и будут присоединены эти посты...

А на каком основании вообще берется файл из кэша? Мы ведь не сохраняем в кэше Partial Content? Значит и читать не имеем права. Пусть так же тянется из инета и в кэш не лезет.

Не работает закачка в два потока не изменившихся html-файлов. Клиент запрашивает файл, сервер отвечает 304, и НС отдает файл из кэша. Клиент снова запрашивает, но уже кусок этого же файла - IMS не вставляется, и сервер отдает нужный кусок. Файл вроде один и тот же, но НС при записи в кэш добавлял в HTML свои тэги, и файл от НС уже не стыкуется с тем куском, который передает сервер. В итоге баг.
Если б НС вставлял IMS в запрос с Range, получил бы и второй раз ответ 304, и мог выдать нужный кусок из кэша без конфликта.

При срабатывании Н и наличии файла в кэше он не просматривается.
Мешает невозможность хранения метаинформации. Но мы рассматриваем пример, когда файл уже весь есть в кэше.
Наоборот, должно было. Только не весь файл, а запрошенная часть.

А по какой причине заглохла эта ветка?
Ведь докачки как не было так и нет.

Хуже того, в связке Опера - Хэндикэш - Глобакс файлы принимаются с ошибками.
Т.е. качаем даже небольшой файл (порядка 1-2 метра) и при нестабильном соединении Хэндикэш начинает закачку заново, но опера об этом почему-то не "узнает" и продолжает закачку как будто закачка продолжилась.
В результате файл испорчен.
В цепочке Опера - Глобакс все корректно докачивается.

Предлагаю научить HC возвращать Partial Content не только из интернета, но и из кэша.
Пример: есть большой файл в кэше и медленный клиент который не успевает за свою сессию скачать этот файл. В результате даже при возможности его качалки продолжить с места разъединения, HC отказывает ему и разрешает качать только весь файл целиком, т.е. с начала.
Есть возможность исправить в будущих версиях?

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

А если запрос отправлять в менеджер закачки? К примеру в ReGet. Или это гемор?