Пазбягайце глабальных змен urllib opener у праверках проксі

Трымайце праверкі проксі праз 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-проксі для публічных праверак. Фрагмент паказвае валоданне; ён не вызначае поўную палітыку аўтэнтыфікацыі ці здароўя. Трымайце любыя handler-ы, спецыфічныя для ўліковага запісу, прымацаванымі да гэтага прызначанага кліента.

urllib.request.install_opener() змяняе працэснае значэнне па змаўчанні, якое выкарыстоўваюць наступныя выклікі urlopen() на ўзроўні модуля. Таму праверка, якая перабірае проксі, можа пакінуць незвязаныя запыты на яе апошняй канчатковай кропцы. Часовая ўстаноўка і аднаўленне пры ачыстцы ўсё яшчэ дазваляюць паралельным запытам выконвацца падчас супольнага змянення.

socket.setdefaulttimeout() аналагічна змяняе значэнні па змаўчанні для sockets, створаных пазней. Выкарыстоўвайце тайм-аўт узроўню аперацыі, калі яго павінна атрымаць толькі праверка.

Закрывайце адказы праверкі і трымайце іх вынікі канкрэтнымі: адказ з памылкай HTTP не азначае аўтаматычна мёртвы слухач проксі. Калі сінхронная праверка urllib выкарыстоўваецца ў асінхронным сэрвісе, перанясіце блакуючую працу ў адпаведны worker; гэта рашэнне аб выкананні не робіць глабальнае змяненне opener ізаляваным.

Праверка павінна вяртаць сваё назіранне, не пакідаючы іншую сеткавую палітыку. Яе ўласны аб'ект кліента і абмежаваная аперацыя робяць гэтую мяжу яўнай.

Падобныя артыкулы