Å lese opplastingen i biter krever ikke chunked HTTP
Skill avgrensede applikasjonslesinger fra HTTP/1.1-meldingsramming når en opplasting oppfører seg annerledes gjennom en videresendende proxy.
Nei. En klient kan lese en stor fil i små buffere og sende den med en kjent Content-Length. Avgrensede lesinger styrer minnebruken; HTTP-rammingen forteller mottakeren hvor forespørselens kropp slutter.
En stabil fil hvis bytelengde HTTP-biblioteket kjenner, er forskjellig fra en generator som produserer en ukjent mengde data. Bruk bibliotekets støttede kroppsgrensesnitt for begge kilder. Du trenger ikke å sette sammen hele filen til en streng bare for å oppgi en lengde.
For HTTP/1.1, undersøk rammingen som faktisk sendes: Content-Length eller chunked overføringskoding etter protokollens regler. Chunked-koding legger til størrelsesmarkører utenfor filinnholdet. Ikke kombiner motstridende rammefelt og ikke gjett en lengde for å overtale en proxy til å godta opplastingen.
Hvis en opplasting gjennom en proxy mislykkes, noter HTTP-versjonen, kroppskilden og den første avvisningen. Et 411-svar peker på en annen undersøkelse enn en tilkobling som lukkes midt i en kropp. Hvis autentiseringsforsøkene i stedet mislykkes, sjekk om opplastingskroppen kan spilles av på nytt. Å endre applikasjonens lesebufferstørrelse kan la forespørselens ramming være nøyaktig som den var.
Ruten er viktig for den observasjonen. Klartekst-videresending eksponerer opplastingens HTTP-ramming for proxyen; vanlig ende-til-ende HTTPS legger den inne i en tunnel. HTTP/2 bruker sin egen ramming. Historiske Squid-begrensninger forklarer derfor bestemte gamle feil, ikke en regel om at enhver nåværende proxy avviser strømmede opplastinger.