اگر یک درخواست مستقیم به تغییرمسیر برسد و تبادل بعدی در یک proxy شکست بخورد، گذار را بررسی کنید. Requests تنظیمات مرتبط با proxy را برای تغییرمسیرها دوباره می‌سازد و ممکن است وقتی Session به آن اعتماد دارد دوباره به محیط مراجعه کند.

مقدار نگاشتآنچه در هنگام ادغام رخ می‌دهد
Noneکلید حذف می‌شود و یک ورودی غایب باقی می‌ماند که گذر بعدی می‌تواند آن را از محیط پر کند.
یک رشته خالیمقدار صریح باقی می‌ماند؛ می‌تواند قصد مسیریابی مستقیم را برای آن طرح حفظ کند.

برای یک Session موجود، طرح‌های مقصد درگیر در عملیات مستقیم را فراهم کنید:

response = session.get(
    'https://example.com/start',
    proxies={'http': '', 'https': ''},
    timeout=15,
)

نگاشت‌های اضافی مخصوص میزبان و آداپتورهای سفارشی را بررسی کنید اگر برنامه آن‌ها را فراهم می‌کند. این ورودی مسیریابی بر هر سیاست ممکنی که آن اجزا پیاده می‌کنند غلبه نمی‌کند.

هر URL را در تشخیص نگه دارید

URL اصلی، هر مکان تغییرمسیر، وضعیت پاسخ و مرحله شکست را ثبت کنید. گذار از HTTP به HTTPS کلید طرح مربوطه را تغییر می‌دهد؛ یک میزبان جدید ممکن است خارج از قاعده عبور میزبان اول قرار بگیرد. گزارشی که فقط URL اولیه را دارد هر دو گذار را پنهان می‌کند.

مشاهده یک پاسخ با غیرفعال بودن دنبال‌کردن تغییرمسیر می‌تواند مرز را آشکار کند. پیش از تصمیم به درخواست آن، مکانش را به‌عنوان داده بررسی کنید؛ اعتبارنامه‌های اصلی را بدون تمایز به مقصد جدید نفرستید.

یک Session اختصاصی با کشف محیط غیرفعال گزینه دیگری است وقتی برنامه آگاهانه مالک همه ورودی‌های مسیریابی و اعتماد است. این بر کشف خودکار اعتبارنامه و CA نیز اثر می‌گذارد، پس آن را به‌عنوان سیاست برنامه انتخاب کنید نه تعمیر روتین تغییرمسیر.

مقالات مرتبط