एउटा थप नयाँ लाइनले CONNECT पछि TLS बिगार्न सक्छ

CONNECT ले 200 फर्काउँदा र TLS ले तुरुन्तै डिकोड गर्न नसकेमा, प्रमाणपत्र वा साइफर बदल्नु अघि कनेक्टरमा रहेका सीमा बाइटहरू जाँच्नुहोस्।

बनाइएको प्राधिकरण मान पहिले नै नयाँ लाइनमा टुंगिन सक्छ। अर्को लाइन-अन्त थप्दा HTTP हेडरहरू चाँडै टुंगिन सक्छन्, जसले इच्छित Host फिल्ड वा अन्य सादा पाठ अनुरोधको पछाडि छोड्छ।

न्यूनतम HTTP/1.1 CONNECT अनुरोधले लाइनहरूबीच CRLF र अन्त्यमा खाली लाइन प्रयोग गर्छ:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

कुनै पनि प्राधिकरण फिल्ड त्यो अन्तिम खाली लाइन अगाडि राख्नुहोस्, भित्र कुनै लाइन ब्रेक बिना। Python मा "\n" ले नयाँ लाइन जनाउँछ; ब्याकस्ल्यास र अक्षर n भएको कच्चा स्ट्रिङले जनाउँदैन। हटाउने प्रयास गर्नु अघि इन्कोडिङ सहायकले कुन बाइटहरू बनाउँछ जाँच्नुहोस्—पुराना सहायकहरूले लाइन ब्रेक थप्न सक्थे।

CONNECT सफल भएपछि, ती बाँकी बाइटहरू सुरुङ प्रोटोकलका हुन्। भुलभुलैयामा परेको सादा पाठ TLS अपेक्षा गर्ने साथीसम्म पुग्न सक्छ। सफल स्थितिले खराब बनेको अनुरोधपछि पहिले नै लाइनमा रहेका बाइटहरू मर्मत गर्न सक्दैन।

प्राप्ति सीमा पनि जाँच्नुहोस्। सकेट TLS लाई सुम्पनु अघि पूरा प्रोक्सी प्रतिक्रिया पढ्नुहोस्, आंशिक पढाइ व्यवस्थापन गर्नुहोस् र हेडरभन्दा पर पढिएको सबै सुरक्षित राख्नुहोस्। एउटा सकेट पढाइमा एउटा पूरा सन्देश हुनु आवश्यक छैन।

यदि यो पार्सर तपाईंको हो भने, सम्पादित बाइट प्रतिनिधित्वलाई तार व्याकरणसँग तुलना गर्नुहोस्; पासवर्ड लुकाउँदै लम्बाइ र लाइन सीमाहरू देखिने राख्नुहोस्। प्रोक्सी जडान मात्र चाहिने अनुप्रयोगका लागि, मर्मत गरिएको कनेक्टरले यो फ्रेमिङ कोड हुनुको आवश्यकता टार्छ।