Č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 kontroliraju potrošnju memorije; HTTP okviri govore 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 upotrijebite sučelje tijela koje biblioteka podržava. Nije potrebno sastavljati cijelu datoteku u string samo da biste naveli duljinu.

Za HTTP/1.1 provjerite stvarno poslane okvire: Content-Length ili chunked prijenosno kodiranje prema pravilima protokola. Chunked kodiranje dodaje oznake veličine izvan sadržaja datoteke. Ne kombinujte proturječna polja okvira 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 autentifikacije, provjerite može li se tijelo prijenosa ponovno odigrati. Promjena veličine čitačkog međuspremnika aplikacije može ostaviti okvire zahtjeva točno kakvi su bili.

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