At lesa uppsendingina í bitum krevur ikki chunked HTTP
Skilj avmarkaðar lesingar í forritinum frá HTTP/1.1-boðskaparramma, tá ein uppsending ber seg ólíkt at gjøgnum ein framproxy.
Nei. Ein klient kann lesa eina stóra fílu í smáum biðminnum og senda hana við einum kendum Content-Length. Avmarkaðar lesingar stýra minnisnýtslu; HTTP-ramman sigur móttakaranum hvar búkurin á fyrispurninginum endar.
Ein støðug fíla, hvørs byte-longd HTTP-bókasavnið veit, er øðrvísi enn ein generator, ið framleiðir eina ókenda nøgd av dáta. Nýt tann búksamskiftið, sum bókasavnið stuðlar, fyri báðar keldu. Tú mást ikki seta alla fíluna saman í ein streng bert fyri at geva eina longd.
Fyri HTTP/1.1, kanna tann ramman, ið veruliga verður send: Content-Length ella chunked transfer coding eftir reglum protokollins. Chunked-koding leggur støddarmerki uttanfyri fíluinnihaldið. Blanda ikki mótsigandi rammureiti og gita ikki eina longd fyri at fáa ein proxy at taka við uppsendingini.
Um ein uppsending gjøgnum proxy miseydnast, skráset HTTP-versjónina, keldu búkin og fyrsta avsláttin. Eitt 411-svar vísir á aðra kanning enn eina samband, ið letur aftur mitt í einum búki. Um váttanarroyndir miseydnast í staðin, kanna um uppsendingarbúkurin kann spælast av nýggjum. At broyta lesibiðminnisstødd forritsins kann lata fyrispurningsrammuna verða júst sum hon var.
Leiðin hevur týdning fyri tað eygleiðingina. Klártekst-leiðing vísir HTTP-rammu uppsendingarinnar fyri proxyinum; vanligt end-til-end HTTPS setur hana inni í einum tunli. HTTP/2 nýtir sína egnu rammu. Tí forklára søgulig Squid-avmarkingar ávísar gomul mistøk, ikki eina reglu um, at hvør núverandi proxy noktar streymaðar uppsendingar.