اختيار وكيل Requests لموقع واحد

يحتاج أحد المواقع إلى وكيل مختلف عن بقية طلبات HTTPS لديك. يستطيع Requests التعبير عن هذا الاختيار داخل قاموس الوكلاء نفسه:

routes = {
    "https://reports.example": "http://reports-proxy.example:8080",
    "https": "http://default-proxy.example:8080",
}
response = requests.get(
    "https://reports.example/monthly",
    proxies=routes,
    timeout=(5, 20),
)
response.raise_for_status()

المفتاح الخاص باسم المضيف هو الذي يفوز لتلك الوجهة. وأي اسم مضيف HTTPS آخر يستخدم المدخل العام للمخطط. القيم تصف اتصال الوكيل، لذا يمكن أن تُقابل وجهة HTTPS بشكل صحيح عنوان وكيل HTTP. وعندما تكون هذه مسارات مواقع عامة مسموحًا بها بلا حسابات وكيل، فإن قائمة وكلاء HTTP يمكن أن توفّر مرشحين لهذه القيم؛ أبقِ كل قاعدة وجهة صريحة.

طابِق اسم المضيف لا عنوان المورد

في Requests 2.32.5 يُبنى المفتاح المحدد من مخطط الوجهة واسم المضيف المُحلَّل. ولا يحتوي على المسار أو الاستعلام أو المنفذ.

إضافة /monthly إلى مفتاح القاموس لن تقصر القاعدة على ذلك المسار. وبالمثل، https://reports.example:8443 ليس مفتاحًا خاصًا بمنفذ يعرفه هذا المحدد. وتُطبَّق قاعدة اسم المضيف أيضًا عندما يستخدم عنوان الوجهة منفذًا آخر.

لا يوجد توسيع بأحرف بدل في هذا البحث. قاعدة لـ reports.example لا تغطي نطاقًا فرعيًا تلقائيًا. استخدم قرار توجيه صريحًا خارج هذا القاموس البسيط عندما تحتاج السياسة إلى مطابقة المسار أو المنفذ أو اللاحقة.

اعرف أي رجوع يأتي بعد ذلك

يتحقق التنفيذ من المفاتيح بهذا الترتيب: scheme://hostname، ثم scheme، ثم all://hostname، ثم all. لذلك فإن مدخل HTTPS العام للمخطط يسبق مدخل اسم المضيف لكل المخططات. ضع قاعدة اسم مضيف خاصة بمخطط في أول تصميمك عندما يكون ذلك هو الاستثناء المقصود.

ضع في الحسبان أيضًا كيف تدمج جلستك (Session) الإعدادات الافتراضية والإعدادات المستمدة من البيئة. تمرير هذين المدخلين الصريحين مع الطلب يجعل مساراتهما المقصودة واضحة، لكنه لا يحدد سياسة لكل مخطط وجهة آخر.

قد يُدخل إعادة التوجيه اسم مضيف آخر، واختيار الوكيل مهم لذلك الوجهة الجديدة أيضًا. اقرأ القاعدة كقرار بشأن كل عنوان URL يُطلب، لا كمسار دائم مرتبط بالصفحة الأولى.