HTTP CONNECT उत्तरानंतर बफरमधील डेटा जतन करा

एक छोटा प्रॉक्सी रॅपर HTTPS साठी काम करू शकतो आणि नंतर अशा प्रोटोकॉलसाठी पुन्हा वापरल्यावर अडकू शकतो ज्याचा सर्व्हर आधी बोलतो. संशयास्पद ओळ बहुतेक वेळा ती असते जी प्राप्ती बफर \r\n\r\n ने संपण्याची वाट पाहत असते.

TCP क्लायंटला स्ट्रीम देतो. एक प्राप्ती कॉल अर्धी HTTP स्टेटस ओळ, पूर्ण CONNECT उत्तर, किंवा ते उत्तर लगेच त्यानंतर टनेल डेटासह परत करू शकतो. वाचन हेडरच्या शेवटी थांबेल असे कोणतेही वचन नाही.

बफरच्या आत सीमा शोधा

HTTP/1.1 CONNECT देवाणघेवाणीसाठी, हेडर समाप्ती चिन्ह बफरमध्ये कुठेही दिसेपर्यंत बाइट्स जमा करा. त्याच्या पहिल्या आढळण्याच्या ठिकाणी विभाजित करा. पहिल्या भागातून स्टेटस ओळ आणि हेडर पार्स करा; सीमेनंतरचे सर्व काही वेगळे ठेवा. प्रतीक्षा करताना हेडर आकार मर्यादा आणि कालमर्यादा लागू करा, आणि रिकाम्या सॉकेट वाचनाला लूपमध्ये जाण्याचे आणखी एक निमंत्रण न मानता बंद कनेक्शन माना.

अंतिम यशस्वी 2xx उत्तर त्या हेडरनंतर लगेच कनेक्शन टनेल मोडमध्ये बदलते. त्यानंतर येणारे बाइट्स आधीच टनेल बाइट्स आहेत. ते टाकून देऊ नका, CONNECT उत्तर बॉडीची वाट पाहू नका, आणि Content-Length फील्डचा अर्थ नवीन प्रोटोकॉलचा भाग वापरण्याची परवानगी असा लावू नका. माहितीपर उत्तरे असल्यास ती त्या अंतिम उत्तरापूर्वी हाताळली पाहिजेत.

रॅपरने आपले उर्वरित पुढे पाठवले पाहिजे

फक्त अंतर्निहित सॉकेट परत केल्यास हँडशेक पार्सरने आधीच त्यातून काढलेले बाइट्स गमावले जातात. पुढील वाचकाला अशी बफर केलेली स्ट्रीम हवी जी प्रथम जतन केलेली शेपूट देते आणि नंतर सॉकेट वाचन पुन्हा सुरू करते. सर्व्हर-प्रथम प्रोटोकॉलमध्ये ते सुरुवातीचे अभिवादन गमावल्यास दोन्ही बाजू अनिश्चित काळ प्रतीक्षा करू शकतात.

उलटपक्षी, अयशस्वी CONNECT उत्तरातील बाइट्स टनेल अभिवादन नाहीत. 407 अजूनही प्रॉक्सी देवाणघेवाणीचा भाग आहे आणि त्याला प्रमाणीकरण हाताळणी हवी; दुसऱ्या अयशस्वी स्थितीला योग्य त्रुटी मार्ग हवा.

हे विशेषतः HTTP प्रॉक्सीद्वारे FTP किंवा SSH क्लायंट जुळवताना महत्त्वाचे आहे. प्रॉक्सीने विनंती केलेला गंतव्य पोर्टही परवानगी देणे आवश्यक आहे, आणि FTP ला अतिरिक्त डेटा कनेक्शन लागू शकतात. योग्य हेडर पार्सिंग स्ट्रीम हस्तांतरण सोडवते; ते CONNECT परवानगी देऊ शकत नाही किंवा FTP चा दुसरा चॅनेल पुरवू शकत नाही.