Čitanje prijenosa u dijelovima ne zahtijeva chunked HTTP

Ne. Klijent može čitati veliku datoteku u malim međuspremnicima i poslati je s poznatim Content-Length. Ograničena čitanja nadziru potrošnju memorije; HTTP uokvirenje govori primatelju gdje završava tijelo zahtjeva.

Stabilna datoteka čiju bajtovnu duljinu HTTP biblioteka zna razlikuje se od generatora koji proizvodi nepoznatu količinu podataka. Za oba izvora rabite sučelje tijela koje biblioteka podržava. Nije potrebno sastavljati cijelu datoteku u niz samo da biste naveli duljinu.

Za HTTP/1.1 provjerite stvarno poslano uokvirenje: Content-Length ili chunked prijenosno kodiranje prema pravilima protokola. Chunked kodiranje dodaje oznake veličine izvan sadržaja datoteke. Ne kombinujte proturječna polja uokvirenja i ne pogađajte duljinu kako biste proxy uvjerili da prihvati prijenos.

Ako prijenos kroz proxy ne uspije, zabilježite inačicu HTTP-a, izvor tijela i prvo odbijanje. Odgovor 411 upućuje na drukčiju istragu od veze koja se zatvara nasred tijela. Ako umjesto toga ne uspiju ponovni pokušaji autentikacije, provjerite može li se tijelo prijenosa ponovno odigrati. Promjena veličine čitačkog međuspremnika aplikacije može ostaviti uokvirenje zahtjeva točno kakvo je bilo.

Ruta je važna za to opažanje. Prijenos otvorenim tekstom izlaže HTTP uokvirenje prijenosa proxyju; običan end-to-end HTTPS stavlja ga u tunel. HTTP/2 rabi vlastito uokvirenje. Povijesna Squid ograničenja stoga objašnjavaju određene stare neuspjehe, a ne pravilo da svaki današnji proxy odbija strujane prijenose.