Configurar cabeceras de proxy con HTTPAdapter.proxy_headers de Requests

Para una cabecera definida por el operador del proxy, Requests expone HTTPAdapter.proxy_headers como punto de sobrescritura:

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 es un ejemplo de campo que entiende este proxy concreto, no una forma estándar de autenticarse ante cualquier intermediario.

Empiece con super().proxy_headers(proxy). Requests usa ese método para generar Proxy-Authorization cuando la URL aporta una cuenta Basic. Sustituir todo el resultado puede perder ese comportamiento.

El adaptador pasa estos valores a ProxyManager de urllib3. En un túnel HTTPS acompañan a CONNECT. El mapeo habitual de cabeceras de solicitud describe la solicitud posterior al destino.

Los gestores de proxy se almacenan en caché por URL de proxy. No trate este gancho como una devolución de llamada sin caché por solicitud de negocio para un valor que deba cambiar en cada llamada. Elija la titularidad del transporte en consecuencia cuando varíe la marca de cuenta.

En el reenvío HTTP simple, los campos de proxy siguen necesitando la política de consumo prevista por el intermediario. Que una cabecera sea específica del proxy en la API de cliente no garantiza la confidencialidad si el proxy la reenvía.