Dersom den nedlastede filen åpner med en HTTP-statuslinje

Når en fil som skal være en PDF eller et regneark åpner med HTTP/1.1 200 OK, har nedlasteren lagret et ubehandlet svar i stedet for filen. Det skjematiske svaret inneholder bare fire byte med innhold:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Det egentlige innholdet er DATA. Statuslinjen, headerne, størrelsesmarkøren og avslutningsstrukturen er HTTP-struktur. Man kan ikke trygt fjerne et bestemt antall byte, siden headerlengdene varierer. Kopierer man alt etter den første blanke linjen, sitter chunk-innrammingen igjen, og informative svar kan komme foran det endelige svaret.

Ved vanlig nedlasting bytter man ut kopieringen fra rå socket til fil med HTTP-klientens grensesnitt for response body. Proxyen settes opp, sluttstatusen valideres, og teksten strømmes til en midlertidig fil. Klienten tar seg av meldingsinnrammingen: lengdebestemte, chunkede og tilkoblingsbestemte tekster krever hver sin parsing.

Innholdskoding kommer i tillegg. Vurder om du trenger dekodede bytes av filen eller rå innhold som er eksplisitt bedt om, og følg klientens dokumenterte atferd. Komprimerte bytes er ikke ensbetydende med at proxyen har ødelagt noe.

Dersom applikasjonen likevel beholder kode på socket-nivå, må den selv håndtere alle disse parsingsreglene og både lesing og skriving. Skriv kun det antallet byte som lesingen faktisk ga, ikke bufferets kapasitet, og håndter delvise skrivinger. Ellers kan gammelt bufferinnhold ødelegge en tekst som er riktig hentet ut.

HTTPS krever mer enn å fjerne CONNECT-svaret: når tunnelen er etablert, må TLS mot målet settes opp før det indre HTTP-svaret parses. De krypterte bytene som følger proxyens headere, er ikke filen du kan laste ned.

Mislykket eller ufullstendig utdata blir liggende under et midlertidig navn. Det publiseres først når overføringen og kontrollene av filen er bestått; en fil som ikke er tom, viser ikke at nedlastingen er komplett.