När den nedladdade filen börjar med en HTTP-statusrad

Om en förmodad PDF eller ett kalkylblad börjar med HTTP/1.1 200 OK har nedladdaren sparat ett råsvar i stället för filen. Detta schematiska svar innehåller bara fyra byte innehåll:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Filen är DATA. Statusraden, rubrikerna, storleksmarkören och avslutningsstrukturen tillhör HTTP. Att ta bort ett fast antal byte är osäkert eftersom rubrikernas längd varierar. Att kopiera allt efter den första tomma raden lämnar fortfarande chunk-inramning, och informativa svar kan komma före det slutliga svaret.

För en vanlig nedladdning ersätter du kopieringen från rå socket till fil med HTTP-klientens gränssnitt för svarskroppen. Konfigurera proxyn, validera slutstatusen och strömma kroppen till en tillfällig utdata. Klienten hanterar meddelandeinramningen: längdavgränsade, chunkade och anslutningsavgränsade kroppar kräver olika parsning.

Innehållskodning är ytterligare ett lager. Bestäm om du behöver avkodade filbyte eller uttryckligen begärt rått innehåll utifrån klientens dokumenterade beteende. Komprimerade byte är inte automatiskt proxykorruption.

Om programmet måste behålla kod på socketnivå ansvarar det för alla dessa parsningsregler samt hantering av läsning och skrivning. Skriv bara antalet byte som läsningen faktiskt returnerade, inte buffertens kapacitet, och hantera partiella skrivningar. Annars kan gammalt buffertinnehåll förstöra även en korrekt uttagen kropp.

HTTPS kräver mer än att ta bort ett CONNECT-svar: efter att tunneln upprättats måste du etablera TLS mot målet och sedan parsa det inre HTTP-svaret. De krypterade byten efter proxyns rubriker är inte den nedladdningsbara filen.

Låt misslyckad eller ofullständig utdata ligga kvar under ett tillfälligt namn. Publicera den först när överföringen och filkontrollerna lyckas; en icke-tom fil visar inte att nedladdningen är komplett.