Երբ ներբեռնված ֆայլը սկսվում է 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 պատասխանը։ Պրոքսի վերնագրերից հետո եկող գաղտնագրված բայթերը ներբեռնվող ֆայլը չեն։

Ձախողված կամ անավարտ ելքը թողեք ժամանակավոր անվան տակ։ Հրապարակեք այն միայն փոխանցման և ֆայլի ստուգումների հաջողությունից հետո. ոչ դատարկ ֆայլը չի ապացուցում ամբողջական ներբեռնում։