Når den downloadede fil begynder med en HTTP-statuslinje

Hvis en påstået PDF eller et regneark begynder med HTTP/1.1 200 OK, har downloaderen gemt et råt svar i stedet for filen. Dette skematiske svar indeholder kun fire bytes indhold:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Filen er DATA. Statuslinjen, headere, størrelsesmarkøren og den afsluttende struktur tilhører HTTP. Det er ikke sikkert at fjerne et fast antal bytes, fordi headerlængder varierer. Kopiering af alt efter den første tomme linje efterlader stadig chunk-rammen, og oplysende svar kan gå forud for det endelige svar.

For en normal download skal du erstatte kopieringen fra rå socket til fil med HTTP-klientens grænseflade for svarlegemet. Konfigurer dens proxy, validér den endelige status og strøm legemet til et midlertidigt output. Klienten håndterer meddelelsesrammen: legemer afgrænset af længde, af chunks og af forbindelse kræver forskellig parsing.

Indholdskodning er et ekstra lag. Afgør, om du har brug for dekodede filbytes eller eksplicit anmodet råt indhold, ud fra klientens dokumenterede adfærd. Komprimerede bytes er ikke automatisk proxy-korruption.

Hvis applikationen skal beholde kode på socket-niveau, ejer den alle disse parsingsregler samt håndtering af læsning og skrivning. Skriv kun det antal bytes, en læsning faktisk returnerer, ikke bufferens kapacitet, og håndtér delvise skrivninger. Ellers kan forældet bufferindhold korrumpere selv et korrekt udtrukket legeme.

HTTPS kræver mere end at strippe et CONNECT-svar: efter vellykket tunnelopsætning skal du etablere destinations-TLS og derefter parse det indre HTTP-svar. De krypterede bytes efter proxyens headere er ikke den downloadbare fil.

Lad mislykket eller ufuldstændigt output ligge under et midlertidigt navn. Offentliggør det først, når overførslen og filkontrollerne lykkes; en ikke-tom fil beviser ikke en fuldstændig download.