Відновлення завантажень через Squid
Перевірте Range-відповіді й ідентичність об’єкта перед відновленням файлу та відрізняйте політику попереднього отримання Squid від базової підтримки діапазонів.
Відновлюйте завантаження лише якщо download.part належить до того самого подання об’єкта, яке ви зараз запитуватимете. Самого імені файлу недостатньо: джерело могло змінити вміст після першої спроби.
curl --proxy http://proxy.example:3128 --noproxy '' --connect-timeout 5 --max-time 60 -C - --output download.part http://files.example/test.binЗамініть обидві кінцеві точки сервісами, якими вам дозволено користуватися. Для порівняння загальнодоступного файлу там, де публічні проксі дозволені, візьміть HTTP-вузол зі списку HTTP-проксі. -C - використовує розмір наявного файлу як точку продовження. Дослідіть відповідь призначення, а не вважайте будь-яке отримане тіло відсутніми байтами:
| Відповідь | Значення |
|---|---|
| 206 із Content-Range | Перевірте, що повернутий діапазон — очікуване продовження. |
| 200 | Сервер міг проігнорувати Range і надіслати повне подання. |
| 416 | Запитаний діапазон неможливо задовольнити; не дописуйте сторінку помилки до файлу. |
Валідатори й If-Range допомагають уникнути склеювання різних версій змінного ресурсу. Дотримуйтеся правил подання застосунку, перш ніж довіряти готовому файлу.
У Squid 6.13 range_offset_limit визначає, коли об’єкт отримується від початку для кешування, а не чи може клієнт запросити діапазон:
range_offset_limit 0Нульова межа виключає зайве отримання початку лише для заповнення кешу. Передавання корисного діапазону без кешування об’єкта все одно може бути успішним. За звичайного HTTPS CONNECT обмін Range перебуває всередині TLS призначення; читайте цю відповідь, а не сприймайте видиму політику об’єктного кешу Squid як керування внутрішнім запитом.