Proxy-headers instellen met HTTPAdapter.proxy_headers van Requests

Voor een header die de proxybeheerder bepaalt, biedt Requests HTTPAdapter.proxy_headers aan als overschrijfpunt:

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 is een voorbeeld van een veld dat deze specifieke proxy begrijpt, niet een standaardmanier om je bij elke tussenpartij te authenticeren.

Begin met super().proxy_headers(proxy). Requests gebruikt die methode om Proxy-Authorization te genereren wanneer de URL een Basic-account levert. Het hele resultaat vervangen kan dat gedrag verliezen.

De adapter geeft deze waarden door aan de ProxyManager van urllib3. Bij een HTTPS-tunnel gaan ze mee met CONNECT. De gewone toewijzing van verzoekheaders beschrijft het latere verzoek naar de bestemming.

Proxybeheerders worden gecachet per proxy-URL. Behandel deze hook niet als een niet-gecachte callback per zakelijk verzoek voor een waarde die bij elke aanroep moet veranderen. Kies het transporteigendom daarop afgestemd wanneer een accountmarkering varieert.

Bij gewone HTTP-doorsturing hebben proxyvelden nog steeds het bedoelde verbruiksbeleid van de tussenpartij nodig. Dat een header proxyspecifiek is in de client-API is geen garantie voor vertrouwelijkheid als de proxy hem doorstuurt.