Amikor a letöltött fájl HTTP állapotsorral kezdődik

Ha egy állítólagos PDF vagy táblázat HTTP/1.1 200 OK-tal kezdődik, a letöltő a fájl helyett nyers választ mentett. Ez a sematikus válasz csak négy bájt tartalmat tartalmaz:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

A fájl a DATA. Az állapotsor, a fejlécek, a méretjelölő és a lezáró szerkezet a HTTP-hez tartozik. Fix számú bájt eltávolítása nem biztonságos, mert a fejlécek hossza változó. Mindennek az első üres sor utáni másolása még mindig meghagyja a darabolási keretezést, és a tájékoztató válaszok megelőzhetik a végső választ.

Normál letöltésnél cserélje le a nyers socketből fájlba másolást a HTTP-kliens választörzs-felületére. Konfigurálja a proxyját, ellenőrizze a végső állapotot, és streamelje a törzset ideiglenes kimenetbe. A kliens kezeli az üzenetkeretezést: a hosszal, darabokkal és kapcsolattal határolt törzsek eltérő feldolgozást igényelnek.

A tartalomkódolás egy további réteg. A kliens dokumentált viselkedése alapján döntse el, hogy dekódolt fájlbájtokra vagy kifejezetten kért nyers tartalomra van-e szüksége. A tömörített bájtok nem automatikusan proxy-korrupciók.

Ha az alkalmazásnak meg kell tartania a socket szintű kódot, akkor mindezek a feldolgozási szabályok, valamint az olvasás és írás kezelése is az övé. Csak az olvasás által ténylegesen visszaadott bájtszámot írja ki, ne a puffer kapacitását, és kezelje a részleges írásokat. Ellenkező esetben az elavult puffertartalom még egy helyesen kinyert törzset is megsérthet.

A HTTPS többre van szükség, mint egy CONNECT-válasz lehántolására: a sikeres alagút-beállítás után hozza létre a cél TLS-t, majd dolgozza fel a belső HTTP-választ. A proxy fejlécei utáni titkosított bájtok nem a letölthető fájl.

A sikertelen vagy hiányos kimenetet hagyja ideiglenes néven. Csak akkor tegye közzé, ha az átvitel és a fájlellenőrzések sikeresek; egy nem üres fájl nem bizonyítja a teljes letöltést.