Að lesa upphleðsluna í bútum krefst ekki chunked HTTP

Nei. Biðlari getur lesið stóra skrá í litlum biðminni og sent hana með þekktu Content-Length. Takmarkaður lestur stýrir minnisnotkun; HTTP-ramminn segir viðtakandanum hvar líkami beiðninnar endar.

Stöðug skrá sem HTTP-safnið þekkir bætalengdina á er frábrugðin skapara sem framleiðir óþekkt magn gagna. Notaðu líkamsviðmótið sem safnið styður fyrir báðar uppsprettur. Þú þarft ekki að setja alla skrána saman í streng bara til að gefa lengd.

Fyrir HTTP/1.1 skaltu skoða rammann sem raunverulega er sendur: Content-Length eða chunked flutningskóðun samkvæmt reglum samskiptareglunnar. Chunked kóðun bætir stærðarmerkjum utan við skráarinnihaldið. Ekki blanda saman misvísandi rammasviðum og giskaðu ekki á lengd til að sannfæra milliþjón um að samþykkja upphleðsluna.

Ef upphleðsla í gegnum milliþjón mistekst skaltu skrá HTTP-útgáfuna, uppsprettu líkamans og fyrstu höfnun. 411 svar bendir til annarrar rannsóknar en tenging sem lokast mitt í líkama. Ef auðkenningartilraunir mistekst í staðinn skaltu athuga hvort hægt sé að spila líkama upphleðslunnar aftur. Að breyta lestrarbiðminnisstærð forritsins getur látið ramma beiðninnar vera nákvæmlega eins og hann var.

Leiðin skiptir máli fyrir þá athugun. Skýrtextaflutningur afhjúpar HTTP-ramma upphleðslunnar fyrir milliþjóninum; venjulegt end-to-end HTTPS setur hann inni í göng. HTTP/2 notar sinn eigin ramma. Því skýra sögulegar Squid-takmarkanir ákveðin gömul mistök, ekki reglu um að sérhver núverandi milliþjón hafni streymdum upphleðslum.