Продолжување преземања преку 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 да ја третирате како контрола на внатрешното барање.