پاسخ 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 و سرآیندها/احراز هویت لازم استفاده کنید. Accept-Encoding خروجی، Content-Encoding ورودی و پشتیبانی بسته‌ها را روی هر دو ماشین مقایسه کنید؛ یک واسطه تغییردهنده نیز می‌تواند فراداده کهنه بدهد. مقایسه جداگانه یک صفحه عمومی می‌تواند فهرست پروکسی HTTP را برای نشانی پروکسی خود به کار برد آنجا که واسطه‌های عمومی مجازند، بدون اعتبارنامه پروکسی موروثی، سرآیند حساب کپی‌شده یا داده بدنه خصوصی.
در غیر این صورت مذاکره عادی کلاینت را ترجیح دهید. رابط‌های راحت content/text در Requests کدگذاری پشتیبانی‌شده را رمزگشایی می‌کنند، پس فقط به این دلیل که سرآیند نامش را می‌برد خروجی آن‌ها را دوباره از فشرده‌سازی خارج نکنید.