Keď stiahnutý súbor začína riadkom stavu HTTP
Nedovoľte, aby sa rámcovanie odpovede HTTP dostalo do stiahnutého artefaktu; namiesto kopírovania každého bajtu prijatého zo socketu proxy do výstupného súboru.
Ak domnelý PDF alebo tabuľka začína HTTP/1.1 200 OK, sťahovač uložil surovú odpoveď namiesto artefaktu. Táto schematická odpoveď obsahuje iba štyri bajty obsahu:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
4
DATA
0
Artefaktom je DATA. Riadok stavu, hlavičky, značka veľkosti a ukončovacia štruktúra patria HTTP. Odstránenie pevného počtu bajtov nie je bezpečné, pretože dĺžky hlavičiek sa líšia. Skopírovanie všetkého po prvom prázdnom riadku stále zanecháva rámcovanie častí, a informatívne odpovede môžu predchádzať záverečnej odpovedi.
Pri bežnom sťahovaní nahraďte kopírovanie zo surového socketu do súboru rozhraním tela odpovede klienta HTTP. Nakonfigurujte jeho proxy, overte konečný stav a streamujte telo do dočasného výstupu. Klient sa stará o rámcovanie správy: telá ohraničené dĺžkou, po častiach (chunked) a ohraničené spojením vyžadujú odlišné parsovanie.
Kódovanie obsahu je ďalšia vrstva. Rozhodnite, či potrebujete dekódované bajty artefaktu alebo výslovne požadovaný surový obsah, podľa dokumentovaného správania klienta. Komprimované bajty nie sú automaticky poškodenie proxy.
Ak aplikácia musí zachovať kód na úrovni socketu, zodpovedá za všetky tieto pravidlá parsovania aj za spracovanie čítania a zápisu. Zapisujte len počet bajtov, ktoré čítanie skutočne vrátilo, nie kapacitu buffera, a spracúvajte čiastočné zápisy. Inak môže zastaraný obsah buffera poškodiť aj správne extrahované telo.
HTTPS vyžaduje viac než odstránenie odpovede CONNECT: po úspešnom vytvorení tunela nastavte TLS k cieľu a potom parsujte vnútornú odpoveď HTTP. Zašifrované bajty po hlavičkách proxy nie sú súborom na stiahnutie.
Neúspešný alebo neúplný výstup ponechajte pod dočasným názvom. Zverejnite ho až po úspešnom prenose a kontrolách artefaktu; neprázdny súbor nedokazuje úplné stiahnutie.