როცა ჩამოტვირთული ფაილი 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 პასუხი. პროქსის სათაურების შემდეგ მომავალი დაშიფრული ბაიტები ჩამოსატვირთი ფაილი არ არის.

წარუმატებელი ან არასრული გამომავალი დატოვეთ დროებითი სახელით. გამოაქვეყნეთ ის მხოლოდ მას შემდეგ, რაც გადაცემა და ფაილის შემოწმებები წარმატებით დასრულდება; არაცარიელი ფაილი სრულ ჩამოტვირთვას არ ამტკიცებს.