Python HTTP प्रॉक्सीचे POST बॉडी rfile मध्ये बफर केले जाऊ शकतात

फॉरवर्ड प्रॉक्सी विनंती ओळ आणि हेडर वाचते, ते पुढे पाठवते, आणि नंतर 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 यंत्रणा समजून घेण्यासाठी उपयुक्त जागा आहे, पण ती उत्पादन फॉरवर्ड-प्रॉक्सी अंमलबजावणी नाही.