Kerülje a globális urllib opener módosításokat a proxy-ellenőrzőkben

Tartsa az urllib proxy-vizsgálatokat a saját openerüknél, ahelyett hogy lecserélné a folyamat szintű útválasztási és időtúllépési alapértelmezéseket.

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.

Hívja meg ennek az openernek a saját open metódusát, amikor egy útvonal a vizsgálathoz tartozik. A példa HTTP végpontja a szolgáltatásából vagy a nyilvános vizsgálatokhoz tartozó HTTP proxy listából származhat. A részlet a tulajdonjogot szemlélteti; nem határozza meg a teljes hitelesítési vagy állapotpolitikát. Tartsa a fiókspecifikus kezelőket ehhez a szánt ügyfélhez kapcsolva.

urllib.request.install_opener() megváltoztatja a folyamat szintű alapértelmezést, amelyet a későbbi modulszintű urlopen() hívások használnak. Ezért a proxykon végigfutó ellenőrző magára hagyhatja a nem kapcsolódó kéréseket az utolsó végpontján. Az ideiglenes telepítés és a tisztításkor történő visszaállítás továbbra is engedi a párhuzamos kérések futását a megosztott módosítás alatt.

socket.setdefaulttimeout() hasonlóképpen megváltoztatja a később létrehozott socketek alapértelmezéseit. Használja a műveletszintű időtúllépést, amikor csak a vizsgálatnak kell megkapnia.

Zárja be a vizsgálati válaszokat, és tartsa az eredményeket konkrétan: a HTTP-hibaválasz nem automatikusan halott proxy-figyelő. Ha szinkron urllib vizsgálatot használ aszinkron szolgáltatásban, helyezze a blokkoló munkát megfelelő dolgozóhoz; ez a végrehajtási döntés nem teszi izolálttá a globális opener módosítást.

A vizsgálatnak vissza kell adnia a megfigyelését anélkül, hogy más hálózati szabályzatot hagyna maga után. Saját ügyfélobjektuma és korlátozott művelete teszi ezt a határt egyértelművé.

Kapcsolódó cikkek