प्रॉक्सी के पीछे Requests का जवाब बिगड़ा दिखता है? Brotli सपोर्ट जाँचें
कॉपी किया गया Accept-Encoding:br होस्टेड Requests परिवेश के डिकोडर सपोर्ट से आगे निकल सकता है।
लैपटॉप और होस्टेड प्रक्रिया की दो अलग परतों पर तुलना करें:
| परत | सवाल |
|---|---|
| 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 और पैकेज सपोर्ट तुलना करें; रूपांतरित करने वाला मध्यस्थ पुराना मेटाडेटा भी दे सकता है। अलग सार्वजनिक पृष्ठ तुलना HTTP प्रॉक्सी सूची का उपयोग अपने प्रॉक्सी URL के लिए कर सकती है जहाँ सार्वजनिक मध्यस्थ अनुमत हैं, बिना विरासत में मिले प्रॉक्सी क्रेडेंशियल, कॉपी किए गए खाता हेडर या निजी बॉडी डेटा के।
अन्यथा सामान्य क्लाइंट बातचीत को प्राथमिकता दें। Requests के सुविधाजनक content/text इंटरफेस समर्थित कोडिंग डिकोड करते हैं, इसलिए केवल इस कारण उनके आउटपुट को फिर से डीकंप्रेस न करें कि हेडर उसका नाम लेता है।