फ़ॉरवर्ड प्रॉक्सी अनुरोध पंक्ति और हेडर पढ़ता है, उन्हें आगे भेजता है, और फिर 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 हैंडलर तंत्र समझने के लिए उपयोगी जगह है, पर वह उत्पादन फ़ॉरवर्ड-प्रॉक्सी कार्यान्वयन नहीं है।

संबंधित लेख