QGIS використовує проксі, а плагін на основі Requests — ні

Шар карти завантажується через офісний проксі, тоді як виклик API плагіна завершується помилкою. Обидві дії виконуються всередині QGIS, але можуть використовувати різні HTTP-клієнти.

QGIS надає QgsNetworkAccessManager для мережевих операцій. Він передає мережеву конфігурацію QGIS у запити, зроблені через цей менеджер. Плагін Python, який імпортує Requests, створює інший клієнт із власною поведінкою проксі та автентифікації.

Виберіть конфігурацію, якою хочете поділитися

Для плагіна, який має дотримуватися мережевих налаштувань QGIS користувача, використання мережевого менеджера QGIS уникає незалежної перебудови цих налаштувань. Перевірте API, що відповідає підтримуваній вами версії QGIS, зокрема його асинхронну поведінку та інтеграцію автентифікації.

Якщо Requests потрібен з іншої причини, налаштуйте його свідомо. Його словник проксі та обробка середовища відповідають документації Requests. Проксі, вибраний у налаштуваннях QGIS, не стає автоматично налаштуванням сесії Requests.

Будьте точними щодо області дії, пробуючи приклади Qt з форуму. Встановлення проксі застосунку Qt впливає на мережу Qt. Це не доводить, що Requests, який використовує іншу мережеву реалізацію, змінив свій маршрут.

Порівняйте ту саму ціль

Порівнюючи поведінку, використовуйте URL плагіна, що не працює. Служба карт і не пов'язаний із нею API можуть мати різні правила обходу, дозволи проксі або ланцюжки сертифікатів. Успішний запит карти доводить лише те, що його власний маршрут працює.

Запишіть назву HTTP-клієнта, цільовий хост, чи запитувалася автентифікація проксі, та фактичний етап помилки. Виключіть паролі з журналів плагіна. Це невелике порівняння зазвичай підказує, чи виправляти мережеву інтеграцію QGIS, чи незалежний клієнт Python, не скидаючи налаштування проксі, які вже працюють для користувача.