Når den nedlasta fila byrjar med ei HTTP-statuslinje

Viss ein påstått PDF eller eit rekneark byrjar med HTTP/1.1 200 OK, lagra nedlastaren eit rått svar i staden for fila. Dette skjematiske svaret inneheld berre fire byte med innhald:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Fila er DATA. Statuslinja, overskriftene, storleiksmerket og avslutningsstrukturen høyrer til HTTP. Å fjerna eit fast tal byte er utrygt fordi lengdene på overskriftene varierer. Kopierer du alt etter den første tomme linja, blir chunk-innramminga likevel att, og informative svar kan koma før det endelege svaret.

For ei vanleg nedlasting bør du byta ut kopieringa frå rå socket til fil med grensesnittet til HTTP-klienten for svartekst. Set opp proxyen, valider den endelege statusen og straum teksten til ei mellombels utdata. Klienten handterer meldingsinnramminga: lengdeavgrensa, chunka og tilkoplingsavgrensa tekstar krev ulik parsing.

Innhaldskoding er eit ekstra lag. Avgjer om du treng dekoda filbyte eller eksplisitt førespurd rå innhald, ut frå den dokumenterte åtferda til klienten. Komprimerte byte er ikkje automatisk proxy-skade.

Viss applikasjonen må halda på kode på socket-nivå, eig han alle desse parsingsreglane og handteringa av lesing og skriving. Skriv berre talet på byte som lesinga faktisk returnerte, ikkje kapasiteten til bufferen, og handter delvise skrivingar. Elles kan gamalt bufferinnhald øydeleggja sjølv ein korrekt utpakka tekst.

HTTPS krev meir enn å fjerna eit CONNECT-svar: etter vellykka tunneloppsett må du etablera TLS mot målet og deretter parsa det indre HTTP-svaret. Dei krypterte byta etter overskriftene til proxyen er ikkje den nedlastbare fila.

Lat mislukka eller ufullstendig utdata liggja under eit mellombels namn. Publiser det først etter at overføringa og filkontrollane er vellykka; ei ikkje-tom fil provar ikkje ei fullstendig nedlasting.