Voorkom globale urllib-opener-wijzigingen in proxycontroles
Houd urllib-proxycontroles lokaal bij hun eigen opener in plaats van procesbrede routering en time-outstandaarden te vervangen.
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.Roep de eigen open-methode van deze opener aan wanneer een route bij de controle hoort. Het HTTP-eindpunt van het voorbeeld kan van uw dienst of van de HTTP-proxylijst voor openbare controles komen. Het fragment illustreert eigendom; het definieert niet het volledige authenticatie- of gezondheidsbeleid. Houd accountspecifieke handlers aan die bedoelde client gekoppeld.
urllib.request.install_opener() wijzigt de procesbrede standaard die latere urlopen()-aanroepen op moduleniveau gebruiken. Een controleur die door proxies loopt kan daardoor ongerelateerde verzoeken met zijn laatste eindpunt laten werken. Tijdelijk installeren en bij het opruimen herstellen laat gelijktijdige verzoeken nog steeds draaien tijdens de gedeelde wijziging.
socket.setdefaulttimeout() wijzigt op dezelfde manier de standaarden voor sockets die daarna worden gemaakt. Gebruik de time-out op operationeel niveau wanneer alleen de controle die moet ontvangen.
Sluit controleantwoorden en houd de resultaten specifiek: een HTTP-foutantwoord is niet automatisch een dode proxylistener. Als een synchrone urllib-controle in een asynchrone dienst wordt gebruikt, verplaats blokkerend werk naar een geschikte worker; die uitvoeringsbeslissing maakt de globale openerwijziging niet geïsoleerd.
Een controle zou haar waarneming moeten teruggeven zonder een ander netwerkbeleid achter te laten. Het eigen clientobject en de begrensde bewerking maken die grens expliciet.