Když stažený soubor začíná stavovým řádkem HTTP
Udržte rámování HTTP odpovědi mimo stažený soubor, místo abyste do výstupního souboru kopírovali každý bajt přijatý z proxy socketu.
Pokud údajný PDF nebo tabulka začíná HTTP/1.1 200 OK, stahovač uložil surovou odpověď místo souboru. Tato schematická odpověď obsahuje pouze čtyři bajty obsahu:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
4
DATA
0
Soubor je DATA. Stavový řádek, hlavičky, značka velikosti a ukončující struktura patří HTTP. Odebrání pevného počtu bajtů není bezpečné, protože délky hlaviček se liší. Zkopírování všeho za prvním prázdným řádkem stále ponechává rámování částí a informační odpovědi mohou předcházet konečné odpovědi.
Pro běžné stahování nahraďte kopírování ze surového socketu do souboru rozhraním těla odpovědi HTTP klienta. Nakonfigurujte jeho proxy, ověřte konečný stav a předejte tělo do dočasného výstupu. Klient se stará o rámování zprávy: těla omezená délkou, po částech a omezená spojením vyžadují odlišné zpracování.
Kódování obsahu je další vrstva. Rozhodněte se, zda potřebujete dekódované bajty souboru, nebo výslovně vyžádaný surový obsah, podle dokumentovaného chování klienta. Komprimované bajty nejsou automaticky poškození proxy.
Pokud aplikace musí zachovat kód na úrovni socketu, vlastní všechna tato pravidla zpracování i obsluhu čtení a zápisu. Zapisujte pouze počet bajtů skutečně vrácených čtením, nikoli kapacitu bufferu, a ošetřete částečné zápisy. Jinak může zastaralý obsah bufferu poškodit i správně vytažené tělo.
HTTPS vyžaduje víc než odstranění odpovědi CONNECT: po úspěšném navázání tunelu vytvořte TLS cíle a poté zpracujte vnitřní HTTP odpověď. Šifrované bajty následující po hlavičkách proxy nejsou stahovaný soubor.
Neúspěšný nebo neúplný výstup ponechte pod dočasným názvem. Zveřejněte jej až po úspěšném přenosu a kontrolách souboru; neprázdný soubor neprokazuje úplné stažení.