It upload yn stikken lêze freget gjin chunked HTTP
Skied begrinze applikaasjelêzingen fan 'e HTTP/1.1-berjochtraming as in upload him oars hâldt troch in foarútproxy.
Nee. In klant kin in grut bestân yn lytse buffers lêze en it mei in bekende Content-Length stjoere. Begrinze lêzingen behearskje it ûnthâldgebrûk; HTTP-raming fertelt de ûntfanger wêr't it lichem fan it fersyk einiget.
In stabyl bestân wêrfan't de HTTP-bibleteek de bytelengte ken, ferskilt fan in generator dy't in ûnbekende hoemannichte gegevens produsearret. Brûk de lichemsynterface dy't de bibleteek stipet foar beide boarnen. Jo hoege net it hiele bestân yn in string gear te stallen allinne om in lingte te jaan.
Foar HTTP/1.1, ûndersykje de raming dy't echt stjoerd wurdt: Content-Length of chunked transfer-codearring neffens de regels fan it protokoly. Chunked-kodearring foeget grutte- Markers ta bûten de bestânynhâld. Kombinearje gjin tsjinstridige ramingsfjilden en riedt gjin lingte om in proxy te oertsjûgjen de upload oan te nimmen.
As in upload fia in proxy mislearret, registrearje dan de HTTP-ferzje, de lichemsboarne en de earste ôfwizing. In 411-antwurd wiist op in oar ûndersyk as in ferbining dy't healweis troch in lichem slút. As ynstee de autentisikaasje- werpogingen mislearje, kontrolearje oft it uploadlichems wer ôfspile wurde kin. It feroarjen fan 'e lêsbuffer- grutte fan 'e applikaasje kin de fersykraming krekt lyk litte as dy wie.
De rûte is wichtich foar dy waarnimming. Iepenbiere tekst trochjaan lit de HTTP-raming fan 'e upload oan 'e proxy sjen; gewoane end-to-end HTTPS set it yn in tunnel. HTTP/2 brûkt syn eigen raming. Dêrom ferklearje histoaryske Squid-beheiningen beskate âlde mislearringen, net in regel dat elke hjoeddeiske proxy streamde uploads wegeret.