Når den nedlastede filen begynner med en HTTP-statuslinje

Hvis en antatt PDF eller et regneark begynner med HTTP/1.1 200 OK, lagret nedlasteren et rått svar i stedet for filen. Dette skjematiske svaret inneholder bare fire byte med innhold:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Filen er DATA. Statuslinjen, overskriftene, størrelsesmarkøren og avslutningsstrukturen tilhører HTTP. Å fjerne et fast antall byte er utrygt fordi overskriftslengdene varierer. Kopierer du alt etter den første tomme linjen, gjenstår fortsatt chunk-innramming, og informative svar kan komme før det endelige svaret.

For en vanlig nedlasting bør du erstatte kopieringen fra rå socket til fil med HTTP-klientens grensesnitt for svartekst. Konfigurer proxyen, valider den endelige statusen og strøm teksten til en midlertidig utdata. Klienten håndterer meldingsinnrammingen: lengdeavgrensede, chunkede og tilkoblingsavgrensede tekster krever ulik parsing.

Innholdskoding er et ekstra lag. Bestem om du trenger dekodede filbytes eller eksplisitt forespurt rått innhold, basert på klientens dokumenterte oppførsel. Komprimerte byte er ikke automatisk proxy-korrupsjon.

Hvis applikasjonen må beholde kode på socket-nivå, eier den alle disse parsingsreglene samt håndtering av lesing og skriving. Skriv bare antall byte som lesingen faktisk returnerte, ikke bufferets kapasitet, og håndter delvise skrivinger. Ellers kan gammelt bufferinnhold ødelegge selv en korrekt utpakket tekst.

HTTPS krever mer enn å fjerne et CONNECT-svar: etter vellykket tunneloppsett må du etablere TLS mot målet og deretter parse det indre HTTP-svaret. De krypterte bytene etter proxyens overskrifter er ikke den nedlastbare filen.

La mislykket eller ufullstendig utdata ligge under et midlertidig navn. Publiser det bare etter at overføringen og filkontrollene er vellykkede; en ikke-tom fil beviser ikke en fullstendig nedlasting.