إعادة توجيه Python Requests: None مقابل قيم proxy الفارغة
اجعل نية التوجيه المباشر صريحة عبر عمليات إعادة التوجيه بدل الاعتماد على قيمة None تُزيل مدخلًا من التعيين.
إذا وصل طلب مباشر إلى إعادة توجيه وفشل التبادل التالي عند proxy، فافحص الانتقال. يعيد Requests بناء الإعدادات المتعلقة بـ proxy لعمليات إعادة التوجيه، وقد يعود إلى البيئة مرة أخرى عندما تثق بها Session.
| قيمة التعيين | ما يحدث أثناء الدمج |
|---|---|
None | يُزال المفتاح، فيبقى مدخل ناقص يمكن لمرور لاحق أن يملأه من البيئة. |
| سلسلة فارغة | تبقى القيمة الصريحة؛ ويمكنها الحفاظ على نية التوجيه المباشر لذلك المخطط. |
بالنسبة إلى Session قائمة، مرّر مخططات الوجهة المشمولة في العملية المباشرة:
response = session.get(
'https://example.com/start',
proxies={'http': '', 'https': ''},
timeout=15,
)افحص أي تعيينات إضافية خاصة بالمضيف ومحوّلات مخصصة إذا كان التطبيق يوفّرها. هذا المدخل للتوجيه لا يتجاوز كل سياسة ممكنة تنفّذها تلك المكوّنات.
أبقِ كل عنوان URL في التشخيص
سجّل عنوان URL الأصلي، وكل موقع لإعادة التوجيه، وحالة الاستجابة، والمرحلة الفاشلة. يغيّر الانتقال من HTTP إلى HTTPS مفتاح المخطط المعني؛ وقد يقع مضيف جديد خارج قاعدة التجاوز الخاصة بالمضيف الأول. التقرير الذي يحتوي على العنوان الأولي فقط يخفي كلا الانتقالين.
يمكن لمراقبة استجابة واحدة مع تعطيل متابعة إعادة التوجيه أن تكشف الحد. افحص موقعه كبيانات قبل أن تقرر طلبه؛ لا ترسل بيانات الاعتماد الأصلية إلى وجهة جديدة دون تمييز.
يُعدّ استخدام Session مخصصة مع تعطيل اكتشاف البيئة خيارًا آخر عندما يتولى التطبيق عمدًا جميع مدخلات التوجيه والثقة. يؤثر ذلك أيضًا في الاكتشاف التلقائي لبيانات الاعتماد وشهادات CA، لذا اختره كسياسة تطبيق لا كإصلاح روتيني لإعادة التوجيه.