আপলোড টুকরো টুকরো করে পড়তে chunked HTTP লাগে না

না। একটি ক্লায়েন্ট বড় ফাইল ছোট বাফারে পড়ে জানা Content-Length নিয়ে পাঠাতে পারে। সীমিত পাঠ মেমরি ব্যবহার নিয়ন্ত্রণ করে; HTTP ফ্রেমিং গ্রাহককে বলে অনুরোধের body কোথায় শেষ হয়।

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

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

প্রক্সির মাধ্যমে আপলোড ব্যর্থ হলে HTTP সংস্করণ, body-র উৎস ও প্রথম প্রত্যাখ্যান লিপিবদ্ধ করুন। 411 প্রতিক্রিয়া body-র মাঝখানে সংযোগ বন্ধ হওয়ার চেয়ে ভিন্ন তদন্তের ইঙ্গিত দেয়। যদি বরং প্রমাণীকরণ পুনঃচেষ্টা ব্যর্থ হয়, দেখুন আপলোড body পুনরায় চালানো যায় কি না। অ্যাপ্লিকেশনের read-buffer মাপ বদলালে অনুরোধের ফ্রেমিং আগের মতোই থাকতে পারে।

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