Избягвайте глобални промени на 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 проверка се използва в асинхронна услуга, преместете блокиращата работа към подходящ работник; това решение за изпълнение не прави глобалната промяна на opener изолирана.

Една проверка трябва да върне наблюдението си, без да оставя друга мрежова политика. Собственият ѝ клиентски обект и ограничената операция правят тази граница явна.