Unngå globale urllib-opener-endringer i proxy-sjekkere
Hold urllib-proxysjekker lokale for sin egen opener i stedet for å erstatte prosessomfattende ruting- og tidsavbruddsstandarder.
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.Kall denne openerens egen open-metode når en rute hører til sjekken. Eksempelets HTTP-endepunkt kan komme fra tjenesten din eller fra HTTP-proxylisten for offentlige sjekker. Utdraget illustrerer eierskap; det definerer ikke den fulle autentiserings- eller helsepolicyen. Hold eventuelle kontospeifikke handlere knyttet til den tiltenkte klienten.
urllib.request.install_opener() endrer prosessomfattende standard som senere urlopen()-kall på modulnivå bruker. En sjekker som går gjennom proxyer kan derfor la urelaterte forespørsler bruke sitt siste endepunkt. Midlertidig installasjon og gjenoppretting under opprydding tillater fortsatt samtidige forespørsler å kjøre under den delte endringen.
socket.setdefaulttimeout() endrer på samme måte standardene for sockets som opprettes senere. Bruk tidsavbruddet på operasjonsnivå når bare sjekken skal motta det.
Lukk sjekkens svar og hold resultatene spesifikke: et HTTP-feilsvar er ikke automatisk en død proxy-lytter. Hvis en synkron urllib-sjekk brukes i en asynkron tjeneste, flytt blokkerende arbeid til en passende worker; den utførelsesbeslutningen gjør ikke den globale opener-endringen isolert.
En sjekk bør returnere observasjonen sin uten å etterlate en annen nettverkspolicy. Dens eget klientobjekt og begrensede operasjon gjør den grensen eksplisitt.