Augšupielādes lasīšana pa daļām neprasa chunked HTTP

Nē. Klients var lasīt lielu failu mazos buferos un sūtīt to ar zināmu Content-Length. Ierobežotās lasīšanas kontrolē atmiņas patēriņu; HTTP ietvars pasaka saņēmējam, kur beidzas pieprasījuma pamatteksts.

Stabils fails, kura baitu garumu zina HTTP bibliotēka, atšķiras no ģeneratora, kas rada nezināmu datu apjomu. Abiem avotiem izmantojiet bibliotēkas atbalstīto pamatteksta saskarni. Nav jāsaliek viss fails virknē tikai tāpēc, lai norādītu garumu.

HTTP/1.1 gadījumā pārbaudiet faktiski nosūtīto ietvaru: Content-Length vai chunked pārsūtīšanas kodējumu saskaņā ar protokola noteikumiem. Chunked kodējums pievieno izmēra marķierus ārpus faila satura. Neapvienojiet pretrunīgus ietvara laukus un neuzminiet garumu, lai pārliecinātu starpniekserveri pieņemt augšupielādi.

Ja augšupielāde caur starpniekserveri neizdodas, pierakstiet HTTP versiju, pamatteksta avotu un pirmo noraidījumu. 411 atbilde norāda uz citu izmeklēšanu nekā savienojums, kas aizveras pamatteksta vidū. Ja tā vietā neizdodas autentifikācijas atkārtojumi, pārbaudiet, vai augšupielādes pamattekstu var atskaņot atkārtoti. Lietotnes lasīšanas bufera lieluma maiņa var atstāt pieprasījuma ietvaru tieši tādu, kāds tas bija.

Maršruts ir svarīgs šim novērojumam. Atklāta teksta pārsūtīšana atklāj augšupielādes HTTP ietvaru starpniekserverim; parasts end-to-end HTTPS ievieto to tunelī. HTTP/2 izmanto savu ietvaru. Tāpēc vēsturiskie Squid ierobežojumi izskaidro konkrētas vecas kļūmes, nevis noteikumu, ka katrs mūsdienu starpniekserveris noraida straumētas augšupielādes.