Калі спампаваны файл пачынаецца з радка стану HTTP

Калі меркаваны PDF або табліца пачынаецца з HTTP/1.1 200 OK, то спампоўшчык захаваў сыры адказ замест файла. Гэты схематычны адказ змяшчае толькі чатыры байты змесціва:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Файл — гэта DATA. Радок стану, загалоўкі, маркер памеру і завяршальная структура належаць HTTP. Выдаляць фіксаваную колькасць байтаў небяспечна, бо даўжыні загалоўкаў розныя. Капіяванне ўсяго пасля першага пустога радка ўсё яшчэ пакідае афармленне блокаў, а інфармацыйныя адказы могуць папярэднічаць канчатковаму адказу.

Для звычайнага спампоўвання замяніце капіяванне з сырога сокета ў файл інтэрфейсам цела адказу HTTP-кліента. Наладзьце яго проксі, праверце канчатковы стан і перадайце цела ў часовы вывад. Кліент апрацоўвае афармленне паведамлення: целы, абмежаваныя даўжынёй, падзеленыя на блокі і абмежаваныя злучэннем, патрабуюць рознага разбору.

Кадаванне змесціва — яшчэ адзін узровень. Вырашыце, ці патрэбны вам дэкадаваныя байты файла, ці яўна запытанае сырое змесціва, абапіраючыся на дакументаваныя паводзіны кліента. Сціснутыя байты — не аўтаматычнае пашкоджанне проксі.

Калі праграма павінна захаваць код на ўзроўні сокета, яна валодае ўсімі гэтымі правіламі разбору, а таксама апрацоўкай чытання і запісу. Запісвайце толькі колькасць байтаў, фактычна вернутых чытаннем, а не ёмістасць буфера, і апрацоўвайце частковыя запісы. Інакш састарэлае змесціва буфера можа пашкодзіць нават правільна вынятае цела.

HTTPS патрабуе большага, чым зняцце адказу CONNECT: пасля паспяховай усталёўкі тунеля ўсталюйце TLS прызначэння і затым разбярыце ўнутраны HTTP-адказ. Зашыфраваныя байты, якія ідуць пасля загалоўкаў проксі, не з'яўляюцца файлам для спампоўвання.

Пакідайце няўдалы або няпоўны вывад пад часовым імем. Апублікуйце яго толькі пасля таго, як перадача і праверкі файла пройдуць; непусты файл не даказвае поўнае спампоўванне.