Zastavte smyčku rotace proxy, aby neběžela navěky
Dejte pythonovému poolu proxy konečný rozpočet pokusů a rozlišujte selhání připojení od odpovědí cíle.
Vrstva mapy se načítá přes kancelářské proxy, zatímco volání API zásuvného modulu selhává. Obě akce běží uvnitř QGIS, ale mohou používat různé HTTP klienty.
QGIS vystavuje QgsNetworkAccessManager pro síťové operace. Přináší síťovou konfiguraci QGIS do požadavků prováděných přes tohoto správce. Zásuvný modul v Pythonu, který importuje Requests, vytváří jiného klienta s vlastním chováním proxy a autentizace.
Zvolte konfiguraci, kterou chcete sdílet
U zásuvného modulu, který má sledovat síťové předvolby uživatele v QGIS, použití síťového správce QGIS zabrání nezávislému znovuvytváření těchto předvoleb. Zkontrolujte API odpovídající verzi QGIS, kterou podporujete, včetně jeho asynchronního chování a integrace autentizace.
Pokud je Requests potřeba z jiného důvodu, nakonfigurujte ho záměrně. Jeho slovník proxy a práce s prostředím se řídí dokumentací Requests. Proxy vybraná v nastavení QGIS není automaticky nastavením relace Requests.
Buďte přesní ohledně rozsahu, když zkoušíte příklady Qt z fóra. Nastavení proxy pro aplikaci Qt ovlivňuje síť Qt. Nedokazuje, že Requests, který používá jinou síťovou implementaci, změnil svou trasu.
Porovnejte stejný cíl
Při porovnávání chování použijte URL selhávajícího zásuvného modulu. Mapová služba a nesouvisející API mohou mít různá pravidla obcházení, oprávnění proxy nebo řetězce certifikátů. Úspěšný požadavek na mapu dokazuje jen to, že jeho vlastní trasa funguje.
Zaznamenejte název HTTP klienta, hostitele cíle, zda bylo vyžádáno ověření proxy, a skutečnou fázi chyby. Vylučte hesla z protokolů zásuvného modulu. Toto malé srovnání obvykle řekne, zda opravit síťovou integraci QGIS, nebo nezávislého klienta Python, aniž byste resetovali předvolby proxy, které uživateli už fungují.