Для загалоўка, які вызначае аператар праксі, Requests прапануе HTTPAdapter.proxy_headers як кропку перавызначэння:

from urllib.parse import urlsplit
import requests
from requests.adapters import HTTPAdapter

class TaggedProxy(HTTPAdapter):
    def proxy_headers(self, proxy):
        headers = super().proxy_headers(proxy)
        endpoint = urlsplit(proxy)
        if (endpoint.scheme == 'http'
                and endpoint.hostname == 'proxy.example'
                and endpoint.port == 8080):
            headers['X-Proxy-Account'] = 'department-a'
        return headers

with requests.Session() as session:
    adapter = TaggedProxy()
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    response = session.get(
        'https://service.example/data',
        proxies={'https': 'http://proxy.example:8080'},
        timeout=15,
    )

X-Proxy-Account — прыклад поля, якое разумее менавіта гэтае праксі, а не стандартны спосаб аўтэнтыфікацыі для любога пасярэдніка.

Пачніце з super().proxy_headers(proxy). Requests выкарыстоўвае гэты метад, каб стварыць Proxy-Authorization, калі URL падае ўліковы запіс Basic. Поўная замена выніку можа знішчыць такія паводзіны.

Адаптар перадае гэтыя значэнні ў ProxyManager з urllib3. Для тунэля HTTPS яны суправаджаюць CONNECT. Звычайная мапа загалоўкаў запыту апісвае наступны запыт да прызначэння.

Менеджэры праксі кэшуюцца па URL праксі. Не разглядайце гэты хук як некешаваны callback для кожнага бізнес-запыту, калі значэнне павінна змяняцца пры кожным выкліку. Выбірайце ўласніка транспарту адпаведна, калі маркер уліковага запісу змяняецца.

Пры звычайнай перадачы HTTP праксі-палі ўсё яшчэ патрабуюць палітыкі спажывання, якую мае на ўвазе пасярэднік. То, што загаловак спецыфічны для праксі ў кліенцкім API, не гарантуе канфідэнцыйнасці, калі праксі перадае яго далей.

Падобныя артыкулы