Пренасочвания в 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 променя съответния ключ на схемата; нов хост може да попадне извън правилото за заобикаляне на първия хост. Доклад само с първоначалния URL скрива и двата прехода.
Наблюдението на един отговор с изключено следване на пренасочвания може да разкрие границата. Прегледайте мястото му като данни, преди да решите да го заявите; не изпращайте безразборно оригиналните идентификационни данни към нова дестинация.
Отделна Session с изключено откриване на средата е друга възможност, когато приложението умишлено притежава всички входове за маршрутизиране и доверие. Това също влияе върху автоматичното откриване на идентификационни данни и CA, затова го изберете като политика на приложението, а не като рутинен ремонт на пренасочване.