ल्यापटप र होस्ट गरिएको प्रक्रियालाई दुई फरक तहमा तुलना गर्नुहोस्:

तहप्रश्न
Content-Encodingके क्लाइन्टले फर्काइएका gzip/deflate/Brotli बाइटहरू डिकम्प्रेस गर्न सक्छ?
Charsetडिकम्प्रेस गरिएका बाइटहरू कसरी पाठ बन्छन्?

Requests सामान्यतया gzip/deflate सम्हाल्छ; Brotli का लागि स्थापित समर्थित लाइब्रेरी चाहिन्छ। हातले प्रतिलिपि गरिएको Accept-Encoding ले br घोषणा गर्न सक्छ जब यो वातावरणले यसलाई डिकोड गर्न सक्दैन। UTF-8 पाठ छनोटले Brotli डिकम्प्रेस गर्दैन।

जब जानाजान वार्तालाप सीमित गरिन्छ:

response = session.get(
    url,
    proxies={"https": "http://proxy.example:8080"},
    headers={"Accept-Encoding": "gzip, deflate"},
    timeout=30,
)
response.raise_for_status()

विद्यमान Session, HTTPS URL र आवश्यक हेडर/प्रमाणीकरण प्रयोग गर्नुहोस्। दुवै मेसिनमा जाने Accept-Encoding, आउने Content-Encoding र प्याकेज समर्थन तुलना गर्नुहोस्; रूपान्तरण गर्ने मध्यस्थले पुरानो मेटाडाटा पनि दिन सक्छ। छुट्टै सार्वजनिक पृष्ठ तुलनाले सार्वजनिक मध्यस्थलाई अनुमति भएको ठाउँमा आफ्नो प्रोक्सी URL का लागि HTTP प्रोक्सी सूची प्रयोग गर्न सक्छ, तर वंशानुगत प्रोक्सी प्रमाणपत्र, प्रतिलिपि गरिएका खाता हेडर वा निजी बडी डाटा बिना।

अन्यथा सामान्य क्लाइन्ट वार्तालापलाई प्राथमिकता दिनुहोस्। Requests का सुविधाजनक content/text इन्टरफेसहरूले समर्थित कोडिङ डिकोड गर्छन्, त्यसैले हेडरले यसको नाम लिएको मात्र कारणले तिनीहरूको आउटपुट फेरि डिकम्प्रेस नगर्नुहोस्।

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