Мне кажется ты не понял о чем речь в этой теме.
Насколько я понял на твоей картинке какая-то программа для закачки файлов и она работает через СКВИД. И пусть работает. Такую работу и сейчас НС поддерживает.
В этой же теме речь идет о том, чтобы НС сам докачивал файлы при обрыве загрузки, программа-клиент может и не знать ничего об обрыве и докачке.

Вообще-то кэшируется, если GET-методом, как на скрине!


Если сам сервер не поддерживает докачку, то и клиент никаких Partial Content не дождется! Что тогда ты хочешь склевать в кэше?


Как раз нужнее то, о чем говорит mai62, т.к. это касается каждого, кто пользуется браузерами, т.е. абсолютно всех!

Например, зашел ты на сайт с большой картинкой. Браузер начал ее качать, но связь оборвалась! После восстановления связи если ты нажмешь "Обновить", то закачка опять начнется с самого начала! Вот в этом случае HC мог бы быстро отдать из кэша скачанное в прошлый раз начало картинки и послать на сервер запрос с Range, чтобы получить только ее окончание!

Разрешить мало. Надо где-то хранить служебную информацию, как-то проверять актуальность имеющихся кусков. И отлаживать все это еще как-то надо.

А если клиент или несколько клиентов будут требовать куски не по порядку? А если размеры кусков будут разными или пересекаться? А если после закачки первого куска файл на сервере изменится (причем, его размер может остаться прежним!)? Проблем много...

В процессе отдачи файла сервером для нас он измениться не может! Т.е. мы на 100% получим рабочий файл, хотя, возможно, уже устаревшую его версию.

Если же запрашивать файл по частям, то после получения начальных кусков, файл может измениться на сервере и конец ты получишь от другого файла!
Склеив их, HC получит битый файл в кэше! Надеюсь, зто понятно?



Слишком частная ситуация! Windows Update вообще мало кто пускает через HC! Чтобы это сделать, нужно поковыряться в реестре. Менеджеры закачек обычно ходят напрямую и качают в несколько потоков и т.д.

А вот браузерами пользуются абсолютно все! Надо делать докачку так, чтобы она пригодилась большинству и чтобы потом не пришлось все переделывать!

Для проверки идентификации файла есть заголовки E-tag, Last modified, к тому же при изменении файла он крайне редко совпадает с новым по размеру. И такая же проблема возникает и менеджеров закачек, но они же все равно поддерживают докачку.
В первом случае клиент не отправляет запрос range. HC, обнаружив запрашиваемый файл в кеше, видит, что тот загружен не до конца (возможно он был загружен даже другим клиентом) отправляет запрос range и если получает ответ partial content докачивает, а клиенту отдает HTTP1.1 200 OK. Первую часть (уже загруженную) отдает из кеша, остальную загружает из интернета.

Хранить информацию о частично закачиваемых файлах (URL, размеры принятых кусков, e-tag, last modified и прочее) можно в отдельном файле. Не понимаю в чем проблема?
Вот менеджеры закачек при паузе и их перезапуске помнят же с на сколько частей они разбивали файл и с какого места.

Но, учитывая скорость выпуска новых версий HC, ожидать появление докачки в нем можно, имхо не раньше, чем через пару лет.

Разумеется. Но ты же предлагаешь писать этот файл в кэш не просто, чтобы он там был и никак не использовался!? Наверное, ты хочешь, чтобы HC выдавал этот файл (или его части) другими клиентам, которые попросят, не качая снова из инета!?
В таком случае, в список "Не обновлять" придется добавить соответствующее правило! А это означает, что HC будет выдавать этот битый файл из кэша и при последующих запросах! Т.е. клиент утрачивает возможность получить корректный файл! Разве не так?


Я его и не расслаблял! Просто пытаюсь выяснить, чем же твоя задача восстребованней и проще в реализации, чем моя.


Согласен. Задачи две, но их реализация пересекается по многим пунктам! И хорошо бы реализовывать их одновременно, чем потом доделывать/переделывать!


Да уж, за последние дни чего только не начитался! Если так пойдет дальше, скоро терпение кончится и начнутся репрессии! 

---

Можно в отдельном файле, можно в индексе, но я предлагаю хранить исходные заголовки прямо в начале временного файла .NEW, которые создает HC при закачке (кроме "chunked")! По моим наблюдениям, все менеджеры закачек именно там их и хранят!


Ну так на то мы и будем хранить заголовки! Content-Length, Last-Modified и ETag позволят однозначно идентифицировать неизменность файла!
Алгоритм докачки, когда клиент ее не поддерживает, примерно такой:
- Клиент прислал повторный запрос на файл, закачка которого в первый раз прервалась.
- HC ищет в кэше его временный файл и читает оттуда информацию о размере скачанной в первый раз части (х) и заголовки.
- HC формирует запрос с заголовком: Range: bytes=(х+1)-  и передает его на сервер.
- При получении ответа 206 сравнивает его заголовки Last-Modified и ETag с соответствующими сохраненными в первый раз. Если этих заголовков нет в 206, то можно извлечь полную длину файла из Content-Range и сравнить ее с Content-Length из первой части.
- Если заголовки совпадают, то HC сразу же отдает клиенту начало файла из кэша и следом качаемое продолжение.
- Если заголовки не совпадают, то HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range). Получаемые данные пишет во временный файл и передает клиенту и т.д. ...

ИМХО, ничего сверхсложного в этой реализации нет...
Добавлено: 04 Декабря 2007, 20:17:07

P.S. При одновременной загрузке одного URL разными клиентами в один и тот же момент времени в кэш пишет тот, кто занял временный файл первым. Собственно, как и сейчас!
В идеале, хорошо бы придерживать параллельные закачки, но это уже совсем другая тема...

Никаких повторных запросов. Надо использовать If-Range.
По размеру сопоставлять некорректно. Это все равно, как если б мы начали сопоставлять по размеру любой файл из кэша, не попадающий в список Н, и в случае совпадения прерывать его загрузку.

Сейчас файл .new в конце закачки просто переименовывается. Если сразу писать в него заголовок, каждый такой файл придется после успешной закачки читать с диска, парсить, отсекая заголовки, а затем писать на диск уже итоговый файл. В подавляющем большинстве случаев это будет пустая работа, т.к. закачка не будет прерванной.
Хорошо бы делать такую запись в файл .new не всегда, а только в тех случаях, когда НС установил, что закачка прервана.

В принципе, да. Нужно лишь делать такое поведение отключаемым.