Python HTTP প্রক্সির POST বডি rfile-এ বাফার করা যায়

ফরওয়ার্ড প্রক্সি অনুরোধের লাইন ও হেডার পড়ে, সেগুলো পাঠায়, তারপর select-এ POST বডির জন্য অপেক্ষা করে। ক্লায়েন্ট ইতিমধ্যে এটি পাঠিয়ে দিয়েছে। দুই পক্ষই একে অপরের জন্য অপেক্ষা করছে বলে মনে হচ্ছে।

Python-এর BaseHTTPRequestHandler-এ হেডার পড়া যায় rfile দিয়ে, যা একটি বাফার করা ইনপুট স্ট্রিম। সেই স্ট্রিম আগে পড়তে পারে এবং বডির বাইট ধরে রাখতে পারে। অন্তর্নিহিত সকেটে অপেক্ষা করা কেবল জিজ্ঞাসা করে এর ফাইল ডেসক্রিপ্টর প্রস্তুত কি না; এটি জিজ্ঞাসা করে না Python স্ট্রিমে ইতিমধ্যে ব্যবহারযোগ্য ডেটা আছে কি না।

যে বাফার হেডার পড়েছে সেটি অনুসরণ করুন

বডিও self.rfile দিয়ে পড়ুন। বাফার করা স্ট্রিম দিয়ে হেডার পার্স করার পর self.connection.recv-এ যাবেন না। নইলে কোড সেই স্ট্রিমে থাকা বাইট এড়িয়ে যেতে পারে এবং এমন ডেটার জন্য অপেক্ষা করতে পারে যা আর কখনও পাঠানো হবে না।

rfile নিজেই select-এ দিলে select তার Python বাফার পরীক্ষা করে না। প্রস্তুততা API অবজেক্টের ফাইল ডেসক্রিপ্টর দিয়ে কাজ করে।

একটি বৈধ Content-Length এবং Transfer-Encoding ছাড়া একটি অনুরোধের জন্য, ঘোষিত বাইট সংখ্যা ঠিক ততটাই গ্রহণ করুন, অকালে ইনপুট শেষ হওয়া এবং আপনার আকার ও সময়সীমা সামলান। EOF পর্যন্ত পড়বেন না: স্থায়ী সংযোগ ব্যবহারকারী ক্লায়েন্ট অনুরোধ শেষ করার পরেও সংযোগ খোলা রাখতে পারে।

ফ্রেমিংকে প্রক্সির স্পষ্ট অংশ করুন

চাঙ্কড অনুরোধ বডির জন্য চাঙ্কড ফ্রেমিং সমর্থন দরকার। অনুপস্থিত Content-Length খুঁজে সেগুলো পড়া যায় না। অস্পষ্ট দৈর্ঘ্য মেটাডেটার জন্য নির্দিষ্ট প্রত্যাখ্যান পথ দরকার, সুবিধাজনক মনে হওয়া হেডার বেছে নেওয়ার বদলে।

ব্লকিং হ্যান্ডলার সীমিত পাঠের সাথে তার স্ট্রিম ইন্টারফেস ব্যবহার চালিয়ে যেতে পারে। ইভেন্ট-চালিত প্রক্সির এমন বাফার মডেল দরকার যা পার্সারের আগে-পড়া ও প্রস্তুততা পরিচালনা একত্রিত করে। টাইমআউট বদলালে একই সকেটের দুই স্বাধীন গ্রাহক মিলবে না।

এই নির্ণয় নির্দিষ্ট করে বলে আগত বাইট কোথায় রাখা হয়। প্রক্সি সঠিক বডি গ্রহণ করার পরেও সেই বডি সুসংগত HTTP ফ্রেমিং দিয়ে পাঠাতে হবে। স্ট্যান্ডার্ড http.server হ্যান্ডলার পদ্ধতিটি বোঝার জন্য উপযুক্ত জায়গা, কিন্তু এটি উৎপাদন ফরওয়ার্ড-প্রক্সি বাস্তবায়ন নয়।