Уникайте глобальних змін opener urllib у перевірках проксі

Тримайте urllib перевірки проксі в межах їхнього власного opener замість заміни процесних налаштувань маршрутизації та тайм-аутів за замовчуванням.

from urllib.request import ProxyHandler, build_opener

def make_proxy_opener(proxy_uri):
    return build_opener(ProxyHandler({
        "http": proxy_uri,
        "https": proxy_uri,
    }))

opener = make_proxy_opener("http://proxy.example.net:8080")
# Use opener.open(destination, timeout=10) for this route.

Викликайте власний метод open цього opener, коли маршрут належить перевірці. Кінцева точка HTTP із прикладу може надходити з вашого сервісу або зі списку HTTP-проксі для публічних перевірок. Фрагмент ілюструє володіння; він не визначає повну політику автентифікації чи здоров'я. Будь-які обробники, специфічні для облікового запису, тримайте прикріпленими до передбачуваного клієнта.

urllib.request.install_opener() змінює процесне значення за замовчуванням, яке використовують подальші виклики urlopen() на рівні модуля. Тому перевіряч, що перебирає проксі, може залишити сторонні запити на своїй останній кінцевій точці. Тимчасове встановлення та відновлення під час очищення все одно дозволяють паралельним запитам виконуватися під час спільної зміни.

socket.setdefaulttimeout() подібно змінює значення за замовчуванням для сокетів, створених пізніше. Використовуйте тайм-аут на рівні операції, коли його має отримати лише перевірка.

Закривайте відповіді перевірки й тримайте результати конкретними: відповідь з помилкою HTTP не означає автоматично мертвий слухач проксі. Якщо синхронна перевірка urllib використовується в асинхронному сервісі, перенесіть блокуючу роботу до відповідного worker; це рішення про виконання не робить глобальну зміну opener ізольованою.

Перевірка має повертати своє спостереження, не залишаючи іншу мережеву політику. Її власний клієнтський об'єкт і обмежена операція роблять цю межу явною.

Схожі статті