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 का दूसरा चैनल प्रदान कर सकती है।