Üleslaadimise tükkhaaval lugemine ei nõua chunked HTTP-d
Eraldage rakenduse piiratud lugemised HTTP/1.1 sõnumiraamistusest, kui üleslaadimine käitub edasisuunalise puhverserveri kaudu teisiti.
Ei. Klient saab lugeda suurt faili väikestesse puhvritesse ja saata selle teadaoleva Content-Lengthiga. Piiratud lugemised juhivad mälukasutust; HTTP raamistus ütleb vastuvõtjale, kus päringu keha lõpeb.
Stabiilne fail, mille baitpikkust HTTP teek teab, erineb generaatorist, mis toodab teadmata koguse andmeid. Kasutage mõlema allika jaoks teegi toetatud keha liidest. Kogu faili ei ole vaja stringi kokku panna ainult pikkuse andmiseks.
HTTP/1.1 puhul uurige tegelikult saadetud raamistust: Content-Length või chunked edastuskodeering vastavalt protokolli reeglitele. Chunked-kodeering lisab suurusemärgid väljapoole faili sisu. Ärge kombineerige vastuolulisi raamistusvälju ega arvake pikkust, et veenda puhverserverit üleslaadimist vastu võtma.
Kui puhverserveri kaudu üleslaadimine ebaõnnestub, registreerige HTTP versioon, keha allikas ja esimene keeldumine. Vastus 411 viitab teistsugusele uurimisele kui keha keskel sulguv ühendus. Kui hoopis autentimiskatsed ebaõnnestuvad, kontrollige, kas üleslaadimise keha saab uuesti esitada. Rakenduse lugemispuhvri suuruse muutmine võib jätta päringu raamistuse täpselt endiseks.
Marsruut on selle vaatluse jaoks oluline. Lihtteksti edastamine paljastab üleslaadimise HTTP raamistuse puhverserverile; tavaline otsast-otsani HTTPS paneb selle tunnelisse. HTTP/2 kasutab oma raamistust. Nii selgitavad ajaloolised Squidi piirangud teatud vanu tõrkeid, mitte reeglit, et iga praegune puhverserver keeldub voogedastatud üleslaadimistest.