For en header, som proxyoperatøren definerer, stiller Requests HTTPAdapter.proxy_headers til rådighed som overstyringspunkt:

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 er et eksempel på et felt, som netop denne proxy forstår, ikke en standardmåde at godkende over for enhver mellemled.

Begynd med super().proxy_headers(proxy). Requests bruger den metode til at generere Proxy-Authorization, når URL'en angiver en Basic-konto. Udskiftning af hele resultatet kan miste den adfærd.

Adapteren sender disse værdier videre til urllib3's ProxyManager. Ved en HTTPS-tunnel følger de med CONNECT. Den almindelige header-mapping for anmodningen beskriver den senere anmodning til destinationen.

Proxy-managere caches pr. proxy-URL. Behandl ikke dette hook som et ikke-cachet callback pr. forretningsanmodning for en værdi, der skal ændres ved hvert kald. Vælg transportejerskab derefter, når en kontomarkør varierer.

Ved almindelig HTTP-videresendelse har proxy-felter stadig brug for mellemleddets tilsigtede forbrugspolitik. At en header er proxyspecifik i klient-API'et er ikke en fortrolighedsgaranti, hvis proxyen videresender den.

Relaterede artikler