Å lese opplastinga i bitar krev ikkje chunked HTTP
Skil avgrensa applikasjonslesingar frå HTTP/1.1-meldingsramming når ei opplasting oppfører seg annleis gjennom ein videresendande proxy.
Nei. Ein klient kan lese ei stor fil i små buffer og sende ho med ein kjend Content-Length. Avgrensa lesingar styrer minnebruken; HTTP-ramminga fortel mottakaren kvar kroppen til førespurnaden sluttar.
Ei stabil fil som HTTP-biblioteket kjenner bytelengda til, er annleis enn ein generator som lagar ei ukjend mengd data. Bruk kroppsgrensesnittet som biblioteket støttar for begge kjeldene. Du treng ikkje setje saman heile fila til ein streng berre for å gje ei lengd.
For HTTP/1.1, gransk ramminga som faktisk vert send: Content-Length eller chunked overføringskoding etter reglane til protokollen. Chunked-koding legg til storleiksmerke utanfor filinnhaldet. Ikkje kombiner motstridande rammefelt og ikkje gjet ei lengd for å overtale ein proxy til å godta opplastinga.
Viss ei opplasting gjennom ein proxy mislukkast, noter HTTP-versjonen, kroppskjelda og den første avvisinga. Eit 411-svar peikar på ei anna gransking enn ei tilkopling som vert stengd midt i ein kropp. Viss autentiseringsforsøka i staden mislukkast, sjekk om opplastingskroppen kan spelast av på nytt. Å endre lesebufferstorleiken til applikasjonen kan la ramminga til førespurnaden vere nøyaktig som ho var.
Ruta er viktig for den observasjonen. Klartekst-vidareformidling syner HTTP-ramminga til opplastinga for proxyen; vanleg ende-til-ende HTTPS legg ho inne i ein tunnel. HTTP/2 brukar si eiga ramming. Historiske Squid-avgrensingar forklarer derfor visse gamle feil, ikkje ei regel om at kvar noverande proxy avviser strøymde opplastingar.