Čtení nahrávání po částech nevyžaduje chunked HTTP
Oddělte omezená čtení aplikace od rámování zpráv HTTP/1.1, když se nahrávání chová přes dopředný proxy odlišně.
Ne. Klient může číst velký soubor do malých bufferů a odeslat jej se známým Content-Length. Omezená čtení řídí spotřebu paměti; rámování HTTP říká příjemci, kde tělo požadavku končí.
Stabilní soubor, jehož délku v bajtech HTTP knihovna zná, se liší od generátoru, který produkuje neznámé množství dat. Pro oba zdroje použijte tělové rozhraní, které knihovna podporuje. Není třeba skládat celý soubor do řetězce jen proto, abyste uvedli délku.
U HTTP/1.1 zkontrolujte skutečně odeslané rámování: Content-Length nebo chunked transfer coding podle pravidel protokolu. Chunked kódování přidává značky velikosti mimo obsah souboru. Nekombinujte protichůdná pole rámování ani nehádejte délku, abyste přiměli proxy nahrávání přijmout.
Pokud nahrávání přes proxy selže, zaznamenejte verzi HTTP, zdroj těla a první odmítnutí. Odpověď 411 naznačuje jiné šetření než spojení, které se zavře uprostřed těla. Pokud místo toho selžou opakované pokusy o ověření, podívejte se, zda lze tělo nahrávání přehrát znovu. Změna velikosti čtecího bufferu aplikace může ponechat rámování požadavku přesně tak, jak bylo.
Na tom pozorování záleží trasa. Přenos otevřeným textem vystavuje rámování HTTP nahrávání proxy; běžné end-to-end HTTPS jej umísťuje do tunelu. HTTP/2 používá vlastní rámování. Historická omezení Squid tedy vysvětlují konkrétní staré poruchy, ne pravidlo, že každý současný proxy odmítá streamovaná nahrávání.