Kui allalaaditud fail algab HTTP olekuriga
Hoidke HTTP-vastuse raamimine allalaaditud failist väljas, selle asemel et kopeerida puhverserveri soklist saadud iga bait väljundfaili.
Kui väidetav PDF või arvutustabel algab HTTP/1.1 200 OK-ga, salvestas allalaadija faili asemel töötlemata vastuse. See skemaatiline vastus sisaldab ainult neli baiti sisu:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
4
DATA
0
Fail on DATA. Olekurida, päised, suuruse marker ja lõpetav struktuur kuuluvad HTTP-le. Fikseeritud arvu baitide eemaldamine ei ole turvaline, sest päiste pikkused erinevad. Kõige kopeerimine pärast esimest tühja rida jätab alles tükkide raamimise, ja informatiivsed vastused võivad eelneda lõplikule vastusele.
Tavalise allalaadimise korral asendage toorsoklist faili kopeerimine HTTP-kliendi vastuse keha liidesega. Seadistage selle puhverserver, valideerige lõplik olek ja voogesitage keha ajutisse väljundisse. Klient haldab sõnumi raamimist: pikkusega, tükkidega ja ühendusega piiratud kehad nõuavad erinevat parsimist.
Sisu kodeerimine on veel üks kiht. Otsustage, kas vajate dekodeeritud faili baite või selgesõnaliselt nõutud toorsisu, tuginedes kliendi dokumenteeritud käitumisele. Kokkusurutud baidid ei ole automaatselt puhverserveri rike.
Kui rakendus peab säilitama sokli tasemel koodi, kuuluvad sellele kõik need parsireeglid ning lugemise ja kirjutamise käsitlemine. Kirjutage ainult see arv baite, mille lugemine tegelikult tagastab, mitte puhvri maht, ja käsitlege osalisi kirjutusi. Vastasel juhul võib aegunud puhvri sisu rikkuda isegi korrektselt eraldatud keha.
HTTPS nõuab enamat kui CONNECT-vastuse eemaldamist: pärast tunnelipüstituse õnnestumist looge sihtkoha TLS ja seejärel parsige sisemine HTTP-vastus. Puhverserveri päistele järgnevad krüptitud baidid ei ole allalaaditav fail.
Jätke ebaõnnestunud või puudulik väljund ajutise nime alla. Avaldage see alles siis, kui ülekanne ja faili kontrollid õnnestuvad; mittetühi fail ei tõesta täielikku allalaadimist.