প্রক্সির পিছনে 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 ইন্টারফেস সমর্থিত কোডিং ডিকোড করে, তাই হেডারে এর নাম থাকলেই আউটপুট আবার ডিকম্প্রেস করবেন না।