Čítanie nahrávania po častiach nevyžaduje chunked HTTP
Oddeľte obmedzené čítania aplikácie od rámovania správ HTTP/1.1, keď sa nahrávanie správa cez dopredný proxy odlišne.
Nie. Klient môže čítať veľký súbor do malých vyrovnávacích pamätí a odoslať ho so známym Content-Length. Obmedzené čítania riadia spotrebu pamäte; rámovanie HTTP hovorí príjemcovi, kde sa telo požiadavky končí.
Stabilný súbor, ktorého dĺžku v bajtoch HTTP knižnica pozná, sa odlišuje od generátora produkujúceho neznáme množstvo dát. Pre oba zdroje použite telové rozhranie, ktoré knižnica podporuje. Nie je potrebné skladať celý súbor do reťazca len preto, aby ste uviedli dĺžku.
Pri HTTP/1.1 skontrolujte skutočne odoslané rámovanie: Content-Length alebo chunked prenosové kódovanie podľa pravidiel protokolu. Chunked kódovanie pridáva značky veľkosti mimo obsahu súboru. Nekombinujte protichodné polia rámovania a nehádajte dĺžku, aby ste proxy presvedčili prijať nahrávanie.
Ak nahrávanie cez proxy zlyhá, zaznamenajte verziu HTTP, zdroj tela a prvé odmietnutie. Odpoveď 411 naznačuje iné vyšetrovanie než spojenie zavreté uprostred tela. Ak namiesto toho zlyhávajú opakované pokusy o overenie, pozrite sa, či sa telo nahrávania dá znova prehrať. Zmena veľkosti čítacej vyrovnávacej pamäte aplikácie môže ponechať rámovanie požiadavky presne také, aké bolo.
Pre toto pozorovanie je dôležitá trasa. Prenos otvoreným textom vystavuje rámovanie HTTP nahrávania proxy; bežné end-to-end HTTPS ho umiestňuje do tunela. HTTP/2 používa vlastné rámovanie. Preto historické obmedzenia Squid vysvetľujú konkrétne staré zlyhania, nie pravidlo, že každý súčasný proxy odmieta streamované nahrávania.