בחירת פרוקסי 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 יכול להתמפות נכון לכתובת URL של פרוקסי HTTP. כאשר אלה מסלולים מורשים של אתרים ציבוריים בלי חשבונות פרוקסי, רשימת פרוקסי ה-HTTP יכולה לספק מועמדים לערכים האלה; שמרו על כל כלל יעד מפורש.

התאימו שם מארח, לא כתובת URL של משאב

ב-Requests 2.32.5 המפתח הספציפי נבנה מהסכימה של היעד ומשם המארח המפורש. הוא אינו מכיל את הנתיב, את השאילתה או את הפורט.

הוספת /monthly למפתח המילון לא תגביל את הכלל לנתיב הזה. באותו אופן, https://reports.example:8443 אינו מפתח ספציפי לפורט שהבורר הזה מזהה. כלל שם המארח חל גם כאשר כתובת ה-URL של היעד משתמשת בפורט אחר.

אין הרחבת תווים כלליים בחיפוש הזה. כלל עבור reports.example אינו מכסה תת-דומיין באופן אוטומטי. השתמשו בהחלטת ניתוב מפורשת מחוץ למילון הפשוט הזה כאשר המדיניות דורשת התאמת נתיב, פורט או סיומת.

דעו איזה גיבוי מגיע לאחר מכן

המימוש בודק מפתחות בסדר הזה: scheme://hostname, scheme, all://hostname ואז all. לכן רשומת HTTPS רוחבית של סכימה קודמת לרשומת שם מארח לכל הסכימות. שימו כלל שם מארח ספציפי לסכימה ראשון בתכנון שלכם כאשר זהו החריג המיועד.

קחו בחשבון גם כיצד ה-Session שלכם ממזג ברירות מחדל והגדרות שמקורן בסביבה. העברת שתי הרשומות המפורשות האלה עם הבקשה מבהירה את המסלולים המיועדים שלהן, אך אינה מגדירה מדיניות לכל סכימת יעד אחרת.

הפניה מחדש יכולה להכניס שם מארח אחר, ובחירת הפרוקסי רלוונטית גם ליעד החדש הזה. קראו את הכלל כהחלטה על כל כתובת URL שמבוקשת, ולא כמסלול קבוע הקשור לעמוד הראשון.