যেতিয়া ডাউনলোড কৰা ফাইলটো 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 সঁহাৰি বিশ্লেষণ কৰক। প্ৰক্সিৰ হেডাৰৰ পিছত অহা এনক্ৰিপ্ট কৰা বাইট ডাউনলোডযোগ্য ফাইল নহয়।

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