फर्वार्ड प्रोक्सीले अनुरोध लाइन र हेडरहरू पढ्छ, तिनीहरूलाई पठाउँछ, त्यसपछि select मा POST बडी पर्खन्छ। ग्राहकले यो पहिले नै पठाइसकेको छ। दुवै पक्ष एकअर्कालाई पर्खिरहेको देखिन्छ।

Python को BaseHTTPRequestHandler मा हेडर पढ्ने काम rfile मार्फत जान्छ, जुन बफर गरिएको इनपुट स्ट्रिम हो। त्यो स्ट्रिमले अगाडि पढ्न सक्छ र बडीसँग सम्बन्धित बाइटहरू राख्न सक्छ। तल्लो socket मा पर्खनुले मात्र त्यसको फाइल डिस्क्रिप्टर तयार छ कि भनेर सोध्छ; Python स्ट्रिममा पहिले नै प्रयोगयोग्य डेटा छ कि भनेर सोध्दैन।

हेडर पढ्ने बफरलाई पछ्याउनुहोस्

बडी पनि self.rfile मार्फत पढ्नुहोस्। बफर गरिएको स्ट्रिमले हेडर पार्स गरेपछि self.connection.recv मा नजानुहोस्। अन्यथा कोडले त्यो स्ट्रिमले राखेका बाइटहरू छोडेर फेरि कहिल्यै नपठाइने डेटा पर्खन सक्छ।

rfile लाई नै select मा दिँदा select ले त्यसको Python बफर जाँच्दैन। तत्परता API वस्तुको फाइल डिस्क्रिप्टरमार्फत काम गर्छ।

एक वैध Content-Length भएको र Transfer-Encoding नभएको अनुरोधका लागि, घोषित बाइट संख्या ठ्याक्कै खपत गर्नुहोस्, इनपुटको अकाल अन्त्य र तपाईंको आकार तथा समय सीमा सम्हाल्नुहोस्। EOF सम्म नपढ्नुहोस्: स्थायी जडान प्रयोग गर्ने ग्राहकले अनुरोध सकिएपछि पनि जडान खुला राख्न सक्छ।

फ्रेमिङलाई प्रोक्सीको स्पष्ट भाग बनाउनुहोस्

चंक गरिएका अनुरोध बडीहरूलाई चंक गरिएको फ्रेमिङ समर्थन चाहिन्छ। अनुपस्थित Content-Length खोजेर तिनीहरू पढ्न सकिँदैन। अस्पष्ट लम्बाइ मेटाडेटालाई सुविधाजनक देखिने हेडर छान्नुको सट्टा परिभाषित अस्वीकृति मार्ग चाहिन्छ।

ब्लकिङ handler ले सीमित पढाइसँग आफ्नो स्ट्रिम इन्टरफेस प्रयोग गर्न सक्छ। घटना-चालित प्रोक्सीलाई पार्सरको अग्रिम पढाइलाई तत्परता व्यवस्थापनसँग एकीकृत गर्ने बफर मोडेल चाहिन्छ। टाइमआउट बदल्दा एउटै socket का दुई स्वतन्त्र उपभोक्ता मिल्ने छैनन्।

यो निदान आउने बाइटहरू कहाँ राखिन्छ भन्नेमा विशिष्ट छ। प्रोक्सीले सही बडी खपत गरिसकेपछि पनि त्यो बडी सुसंगत HTTP फ्रेमिङसँग पठाउनुपर्छ। मानक http.server handler यन्त्रणा बुझ्न उपयोगी ठाउँ हो, तर यो उत्पादन फर्वार्ड-प्रोक्सी कार्यान्वयन होइन।

सम्बन्धित लेखहरू