আপলোড টুকুৰি টুকুৰিকৈ পঢ়িবলৈ chunked HTTP নালাগে

নহয়। এটা ক্লায়েন্টে ডাঙৰ ফাইল সৰু বাফাৰত পঢ়িব পাৰে আৰু জনা Content-Lengthৰ সৈতে পঠিয়াব পাৰে। সীমাবদ্ধ পঢ়াই মেমৰি ব্যৱহাৰ নিয়ন্ত্ৰণ কৰে; HTTP ফ্ৰেমিঙে গ্ৰাহকক অনুৰোধৰ body ক'ত শেষ হয় সেই কথা কয়।

HTTP লাইব্ৰেৰীয়ে যাৰ byte দৈৰ্ঘ্য জানে এনে স্থিৰ ফাইল আৰু অপৰিচিত পৰিমাণৰ ডাটা উৎপন্ন কৰা জেনাৰেটৰ বেলেগ। দুয়োটা উৎসৰ বাবে লাইব্ৰেৰীয়ে সমৰ্থন কৰা body ইন্টাৰফেচ ব্যৱহাৰ কৰক। কেৱল দৈৰ্ঘ্য দিবলৈ গোটেই ফাইলটো এটা stringত জমা কৰাৰ প্ৰয়োজন নাই।

HTTP/1.1ৰ বাবে প্ৰটোকলৰ নিয়ম অনুসৰি আচলতে পঠিওৱা ফ্ৰেমিং পৰীক্ষা কৰক: Content-Length বা chunked transfer coding। Chunked codingে ফাইলৰ সমলৰ বাহিৰত আকাৰৰ চিহ্ন যোগ কৰে। বিৰোধী ফ্ৰেমিং ফিল্ড একত্ৰিত নকৰিব বা প্রক্সিয়ে আপলোড গ্ৰহণ কৰাটো বুজাবলৈ দৈৰ্ঘ্য অনুমান নকৰিব।

প্রক্সিৰ মাজেৰে যোৱা আপলোড বিফল হ'লে HTTP সংস্কৰণ, bodyৰ উৎস আৰু প্ৰথম অস্বীকৃতি লিপিবদ্ধ কৰক। 411 উত্তৰে bodyৰ মাজতে সংযোগ বন্ধ হোৱাৰ পৰা পৃথক তদন্তৰ ইংগিত দিয়ে। যদি ইয়াৰ পৰিৱৰ্তে প্ৰমাণীকৰণ পুনৰ চেষ্টা বিফল হয়, আপলোডৰ body পুনৰ বজাব পাৰি নেকি চাওক। এপ্লিকেচনৰ read-bufferৰ আকাৰ সলনি কৰিলে অনুৰোধৰ ফ্ৰেমিং আগৰ দৰেই থাকিব পাৰে।

সেই পৰ্যবেক্ষণৰ বাবে পথটো গুৰুত্বপূৰ্ণ। Plaintext forwardingে আপলোডৰ HTTP ফ্ৰেমিং প্রক্সিৰ আগত উন্মুক্ত কৰে; সাধাৰণ end-to-end HTTPSে ইয়াক tunnelৰ ভিতৰত ৰাখে। HTTP/2য়ে নিজৰ ফ্ৰেমিং ব্যৱহাৰ কৰে। সেয়ে ঐতিহাসিক Squid সীমাই নির্দিষ্ট পুৰণি বিফলতা ব্যাখ্যা কৰে, বৰ্তমানৰ প্রতিটো প্রক্সিয়ে streamed আপলোড নাকচ কৰে বুলি নিয়ম নহয়।