استجابة 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 تفكّ الترميز المدعوم، لذا لا تفكّ ضغط مخرجاتها مرة أخرى لمجرد أن الترويسة تذكر اسمه.

مقالات ذات صلة