Configurar cabeceiras de proxy con HTTPAdapter.proxy_headers de Requests

Para unha cabeceira definida polo operador do proxy, Requests expón HTTPAdapter.proxy_headers como punto de substitución:

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 é un exemplo de campo que entende este proxy concreto, non unha forma estándar de autenticarse ante calquera intermediario.

Comece con super().proxy_headers(proxy). Requests usa ese método para xerar Proxy-Authorization cando o URL achega unha conta Basic. Substituír todo o resultado pode perder ese comportamento.

O adaptador pasa estes valores a ProxyManager de urllib3. Nun túnel HTTPS acompañan CONNECT. A asignación habitual de cabeceiras de solicitude describe a solicitude posterior ao destino.

Os xestores de proxy gárdanse en caché por URL de proxy. Non trate este gancho como unha chamada de retorno sen caché por solicitude de negocio para un valor que deba cambiar en cada chamada. Escolla a titularidade do transporte en consecuencia cando varíe a marca de conta.

No reenvío HTTP simple, os campos de proxy seguen necesitando a política de consumo prevista polo intermediario. Que unha cabeceira sexa específica do proxy na API de cliente non garante confidencialidade se o proxy a reenvía.