Branje nalaganja po kosih ne zahteva chunked HTTP

Ne. Odjemalec lahko bere veliko datoteko v majhnih medpomnilnikih in jo pošlje z znanim Content-Length. Omejena branja nadzorujejo porabo pomnilnika; uokvirjanje HTTP pove prejemniku, kje se telo zahteve konča.

Stabilna datoteka, katere bajtno dolžino pozna knjižnica HTTP, se razlikuje od generatorja, ki ustvarja neznano količino podatkov. Za oba vira uporabite vmesnik telesa, ki ga knjižnica podpira. Ni treba sestaviti celotne datoteke v niz samo zato, da navedete dolžino.

Pri HTTP/1.1 preglejte dejansko poslano uokvirjanje: Content-Length ali chunked prenosno kodiranje po pravilih protokola. Chunked kodiranje doda oznake velikosti zunaj vsebine datoteke. Ne združujte nasprotujočih si polj uokvirjanja in ne ugibajte dolžine, da bi prepričali proxy, naj sprejme nalaganje.

Če nalaganje skozi proxy ne uspe, zabeležite različico HTTP, vir telesa in prvo zavrnitev. Odgovor 411 nakazuje drugačno preiskavo kot povezava, ki se zapre na sredini telesa. Če namesto tega ne uspejo ponovni poskusi preverjanja pristnosti, preverite, ali je mogoče telo nalaganja znova predvajati. Sprememba velikosti bralnega medpomnilnika aplikacije lahko pusti uokvirjanje zahteve natanko tako, kot je bilo.

Pot je pomembna za to opažanje. Posredovanje v čistem besedilu izpostavi uokvirjanje HTTP nalaganja proxyju; običajen HTTPS od konca do konca ga postavi v tunel. HTTP/2 uporablja lastno uokvirjanje. Zato zgodovinske omejitve Squid pojasnjujejo določene stare okvare, ne pa pravila, da vsak današnji proxy zavrača pretakana nalaganja.