Įkėlimo skaitymas dalimis nereikalauja chunked HTTP

Ne. Klientas gali skaityti didelį failą mažuose buferiuose ir siųsti jį su žinomu Content-Length. Apriboti skaitymai kontroliuoja atminties naudojimą; HTTP rėminimas pasako gavėjui, kur baigiasi užklausos turinys.

Stabilus failas, kurio ilgį baitais žino HTTP biblioteka, skiriasi nuo generatoriaus, kuris sukuria nežinomą duomenų kiekį. Abiem šaltiniams naudokite bibliotekos palaikomą turinio sąsają. Nereikia surinkti viso failo į eilutę vien tam, kad nurodytumėte ilgį.

HTTP/1.1 atveju patikrinkite faktiškai siunčiamą rėminimą: Content-Length arba chunked perdavimo koduotę pagal protokolo taisykles. Chunked koduotė prideda dydžio žymeklius už failo turinio ribų. Nekombinuokite prieštaringų rėminimo laukų ir neatspėkite ilgio, kad įtikintumėte proxy priimti įkėlimą.

Jei įkėlimas per proxy nepavyksta, užrašykite HTTP versiją, turinio šaltinį ir pirmą atmetimą. 411 atsakymas rodo kitokį tyrimą nei jungtis, kuri užsidaro per vidurį turinio. Jei vietoj to nepavyksta autentifikavimo pakartojimai, patikrinkite, ar įkėlimo turinį galima paleisti iš naujo. Programos skaitymo buferio dydžio pakeitimas gali palikti užklausos rėminimą tokį, koks buvo.

Maršrutas svarbus tam stebėjimui. Atviro teksto perdavimas atskleidžia įkėlimo HTTP rėminimą proxy; įprastas ištisinis HTTPS įdeda jį į tunelį. HTTP/2 naudoja savo rėminimą. Todėl istoriniai Squid apribojimai paaiškina konkrečius senus gedimus, o ne taisyklę, kad kiekvienas dabartinis proxy atmeta srautinius įkėlimus.