Pour un en-tête défini par l'exploitant du proxy, Requests expose HTTPAdapter.proxy_headers comme point de substitution :

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 illustre un champ compris par ce proxy précis, et non un moyen standard de s'authentifier auprès de tout intermédiaire.

Partez de super().proxy_headers(proxy). Requests utilise cette méthode pour générer Proxy-Authorization lorsque l'URL fournit un compte Basic. Remplacer tout le résultat peut faire perdre ce comportement.

L'adaptateur transmet ces valeurs au ProxyManager d'urllib3. Pour un tunnel HTTPS, elles accompagnent CONNECT. La correspondance ordinaire des en-têtes de requête décrit la requête ultérieure vers la destination.

Les gestionnaires de proxy sont mis en cache par URL de proxy. Ne traitez pas ce crochet comme un rappel non mis en cache par requête métier pour une valeur qui doit changer à chaque appel. Choisissez la propriété du transport en conséquence lorsqu'un marqueur de compte varie.

En transfert HTTP simple, les champs de proxy ont toujours besoin de la politique de consommation prévue par l'intermédiaire. Qu'un en-tête soit propre au proxy dans l'API client ne garantit pas la confidentialité si le proxy le transmet.

Articles similaires