Ställ in proxy-huvuden med Requests HTTPAdapter.proxy_headers

För ett huvud som proxyoperatören definierar erbjuder Requests HTTPAdapter.proxy_headers som åsidosättningspunkt:

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 är ett exempel på ett fält som just denna proxy förstår, inte ett standardiserat sätt att autentisera mot varje mellanhand.

Börja med super().proxy_headers(proxy). Requests använder den metoden för att generera Proxy-Authorization när URL:en anger ett Basic-konto. Att ersätta hela resultatet kan förlora det beteendet.

Adaptern skickar dessa värden vidare till urllib3s ProxyManager. I en HTTPS-tunnel följer de med CONNECT. Den vanliga mappningen av begärandehuvuden beskriver den senare begäran till målet.

Proxy-hanterare cachelagras per proxy-URL. Behandla inte denna krok som en ocachad återkallelse per affärsbegäran för ett värde som måste ändras vid varje anrop. Välj transportägarskap därefter när en kontomarkör varierar.

Vid vanlig HTTP-vidarebefordran behöver proxyfält fortfarande mellanhandens avsedda användningspolicy. Att ett huvud är proxyspecifikt i klientens API är ingen garanti för konfidentialitet om proxyn vidarebefordrar det.