যখন ডাউনলোড করা ফাইল 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 রেসপন্স পার্স করুন। প্রক্সির হেডারের পরের এনক্রিপ্ট করা বাইট ডাউনলোডযোগ্য ফাইল নয়।

ব্যর্থ বা অসম্পূর্ণ আউটপুট একটি অস্থায়ী নামে রাখুন। স্থানান্তর এবং ফাইল যাচাই সফল হওয়ার পরেই তা প্রকাশ করুন; খালি নয় এমন ফাইল সম্পূর্ণ ডাউনলোড প্রমাণ করে না।