Leximi i ngarkimit në copa nuk kërkon HTTP të copëzuar

Jo. Një klient mund të lexojë një skedar të madh në bufera të vegjël dhe ta dërgojë me një Content-Length të njohur. Leximet e kufizuara kontrollojnë përdorimin e kujtesës; strukturimi HTTP i tregon marrësit ku përfundon trupi i kërkesës.

Një skedar i qëndrueshëm, gjatësinë në bajt të të cilit e njeh biblioteka HTTP, është i ndryshëm nga një gjenerator që prodhon një sasi të panjohur të dhënash. Për secilin burim përdorni ndërfaqen e trupit që biblioteka mbështet. Nuk ju duhet ta montoni të gjithë skedarin në një varg vetëm për të dhënë një gjatësi.

Për HTTP/1.1, shikoni strukturimin e dërguar në të vërtetë: Content-Length ose kodimin e transferimit në copa sipas rregullave të protokollit. Kodimi në copa shton shënues madhësie jashtë përmbajtjes së skedarit. Mos kombinoni fusha strukturimi kontradiktore dhe mos hamendësoni një gjatësi për ta bindur një proxy të pranojë ngarkimin.

Nëse një ngarkim përmes proxy dështon, regjistroni versionin HTTP, burimin e trupit dhe refuzimin e parë. Një përgjigje 411 sugjeron një hetim të ndryshëm nga një lidhje që mbyllet në mes të një trupi. Nëse në vend të kësaj dështojnë ripërpjekjet e vërtetimit, kontrolloni nëse trupi i ngarkimit mund të riluhet. Ndryshimi i madhësisë së buferit të leximit të aplikacionit mund ta lërë strukturimin e kërkesës pikërisht siç ishte.

Rruga ka rëndësi për atë vëzhgim. Përcjellja në tekst të thjeshtë ia ekspozon proxy-t strukturimin HTTP të ngarkimit; HTTPS normal nga skaji në skaj e vendos atë brenda një tuneli. HTTP/2 përdor strukturimin e vet. Kufizimet historike të Squid, pra, shpjegojnë dështime të veçanta të vjetra, jo një rregull që çdo proxy i sotëm i refuzon ngarkimet e transmetuara.