Продължаване на изтегляния през 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 като контрол на вътрешната заявка.