At læse uploaden i bidder kræver ikke chunked HTTP
Adskil afgrænsede applikationslæsninger fra HTTP/1.1-meddelelsesrammer, når en upload opfører sig anderledes gennem en forward-proxy.
Nej. En klient kan læse en stor fil i små buffere og sende den med en kendt Content-Length. Afgrænsede læsninger styrer hukommelsesforbruget; HTTP-rammer fortæller modtageren, hvor anmodningens body slutter.
En stabil fil, hvis bytelængde HTTP-biblioteket kender, er forskellig fra en generator, der producerer en ukendt mængde data. Brug bibliotekets understøttede body-grænseflade til begge kilder. Du behøver ikke samle hele filen i en streng bare for at angive en længde.
For HTTP/1.1 skal du undersøge den ramme, der faktisk sendes: Content-Length eller chunked transfer coding efter protokollens regler. Chunked-kodning tilføjer størrelsesmarkører uden for filindholdet. Kombiner ikke modstridende rammefelter, og gæt ikke en længde for at få en proxy til at acceptere uploaden.
Hvis en upload gennem en proxy mislykkes, skal du notere HTTP-versionen, body-kilden og den første afvisning. Et 411-svar peger på en anden undersøgelse end en forbindelse, der lukker midt i en body. Hvis godkendelsesforsøg i stedet mislykkes, så tjek om uploadens body kan afspilles igen. Ændring af applikationens læsebufferstørrelse kan efterlade anmodningens ramme præcis som den var.
Ruten er vigtig for den observation. Klartekst-videresendelse blotlægger uploadens HTTP-ramme for proxyen; almindelig end-to-end HTTPS lægger den inde i en tunnel. HTTP/2 bruger sin egen ramme. Historiske Squid-begrænsninger forklarer derfor bestemte gamle fejl, ikke en regel om, at enhver nuværende proxy afviser streamede uploads.