सानो प्रोक्सी र्यापर HTTPS का लागि काम गर्न सक्छ र त्यसपछि सर्भर पहिले बोल्ने प्रोटोकलका लागि पुन: प्रयोग गर्दा अड्किन सक्छ। शंकास्पद लाइन प्रायः त्यही हुन्छ जसले प्राप्ति बफर \r\n\r\n सँग अन्त्य हुन पर्खिरहेको हुन्छ।

TCP ले क्लाइन्टलाई स्ट्रिम दिन्छ। एउटा प्राप्ति कलले आधा HTTP स्थिति लाइन, पूरा CONNECT प्रतिक्रिया, वा त्यो प्रतिक्रियालगत्तै टनेल डेटा फर्काउन सक्छ। पढाइ हेडरको अन्त्यमा रोकिन्छ भन्ने कुनै वाचा छैन।

बफरभित्र सीमा खोज्नुहोस्

HTTP/1.1 CONNECT आदानप्रदानका लागि, हेडर समाप्ति चिन्ह बफरमा कहीं पनि नदेखिएसम्म बाइटहरू जम्मा गर्नुहोस्। यसको पहिलो देखा पर्ने ठाउँमा विभाजन गर्नुहोस्। पहिलो भागबाट स्थिति लाइन र हेडर पार्स गर्नुहोस्; सीमापछिको सबै कुरा छुट्टै राख्नुहोस्। पर्खँदा हेडर आकार सीमा र समयसीमा लागू गर्नुहोस्, र खाली सकेट पढाइलाई लूपमा जाने अर्को निम्तो नमानी बन्द जडान मान्नुहोस्।

अन्तिम सफल 2xx प्रतिक्रियाले ती हेडरपछि तुरुन्तै जडानलाई टनेल मोडमा बदल्छ। त्यसपछि आउने बाइटहरू पहिले नै टनेल बाइट हुन्। तिनीहरूलाई नफाल्नुहोस्, CONNECT प्रतिक्रिया बडीको प्रतीक्षा नगर्नुहोस्, र Content-Length फिल्डलाई नयाँ प्रोटोकलको भाग उपभोग गर्ने अनुमति ठान्नुहोस्। सूचनात्मक प्रतिक्रियाहरू भए ती त्यो अन्तिम प्रतिक्रियाअघि सम्हालिनुपर्छ।

र्यापरले आफ्ना बाँकी कुरा अगाडि पठाउनुपर्छ

केवल अन्तर्निहित सकेट फर्काउँदा ह्यान्डशेक पार्सरले पहिले नै त्यसबाट तानेका बाइटहरू हराउँछन्। अर्को पाठकलाई पहिले सुरक्षित गरिएको पुच्छर दिने र त्यसपछि सकेट पढाइ पुन: सुरु गर्ने बफर गरिएको स्ट्रिम चाहिन्छ। सर्भर-पहिलो प्रोटोकलका लागि त्यो सुरुको अभिवादन गुमाउँदा दुवै पक्ष अनन्तकाल पर्खिरहन सक्छन्।

यसको विपरीत, असफल CONNECT प्रतिक्रियाका बाइटहरू टनेल अभिवादन होइनन्। 407 अझै पनि प्रोक्सी आदानप्रदानकै हो र यसलाई प्रमाणीकरण हेरचाह चाहिन्छ; अर्को असफल स्थितिलाई उपयुक्त त्रुटि मार्ग चाहिन्छ।

यो विशेषगरी HTTP प्रोक्सीमार्फत FTP वा SSH क्लाइन्ट अनुकूलन गर्दा महत्त्वपूर्ण हुन्छ। प्रोक्सीले अनुरोध गरिएको गन्तव्य पोर्ट पनि अनुमति दिनुपर्छ, र FTP लाई थप डेटा जडान चाहिन सक्छ। सही हेडर पार्सिङले स्ट्रिम हस्तान्तरण समाधान गर्छ; यसले CONNECT अनुमति दिन वा FTP को दोस्रो च्यानल उपलब्ध गराउन सक्दैन।

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