Att läsa uppladdningen i bitar kräver inte chunked HTTP
Skilj avgränsade appläsningar från HTTP/1.1-meddelandets framing när en uppladdning beter sig annorlunda genom en forward proxy.
Nej. En klient kan läsa en stor fil i små buffertar och skicka den med en känd Content-Length. Avgränsade läsningar styr minnesanvändningen; HTTP-framing talar om för mottagaren var förfrågans body slutar.
En stabil fil vars bytelängd HTTP-biblioteket känner till skiljer sig från en generator som producerar en okänd mängd data. Använd bibliotekets body-gränssnitt som stöds för båda källorna. Du behöver inte sätta ihop hela filen till en sträng bara för att ange en längd.
För HTTP/1.1, granska den framing som faktiskt skickades: Content-Length eller chunked transfer coding enligt protokollets regler. Chunked-kodning lägger till storleksmarkörer utanför filinnehållet. Kombinera inte motstridiga framingfält och gissa inte en längd för att få en proxy att acceptera uppladdningen.
Om en uppladdning via proxy misslyckas, registrera HTTP-versionen, bodykällan och det första avvisandet. Ett 411-svar antyder en annan undersökning än en anslutning som stängs mitt i en body. Om autentiseringsförsök i stället misslyckas, kontrollera om uppladdningens body kan spelas upp igen. Att ändra applikationens läsbuffertstorlek kan lämna förfrågans framing precis som den var.
Vägen spelar roll för den observationen. Klartextsforwarding exponerar uppladdningens HTTP-framing för proxyn; vanlig HTTPS från ände till ände placerar den inuti en tunnel. HTTP/2 använder sin egen framing. Historiska Squid-begränsningar förklarar därför vissa gamla fel, inte en regel att varje nuvarande proxy avvisar strömmade uppladdningar.