Proxy-headers ynstelle mei HTTPAdapter.proxy_headers fan Requests

Foar in header dy't troch de proxy-operator bepaald wurdt, biedt Requests HTTPAdapter.proxy_headers as oerskriuwpunt oan:

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 in foarbyld fan in fjild dat dizze spesifike proxy begrypt, net in standert manier om by elk tuskenstasjon te autentisearjen.

Begjin mei super().proxy_headers(proxy). Requests brûkt dy metoade om Proxy-Authorization te meitsjen as de URL in Basic-account leveret. It hiele resultaat ferfange kin dat gedrach ferlieze.

De adapter jout dizze wearden troch oan ProxyManager fan urllib3. By in HTTPS-tunnel geane se mei CONNECT. De gewoane oanfraachheader-mapping beskriuwt de lettere oanfraach nei de bestimming.

Proxy-behearders wurde per proxy-URL cachet. Behandel dizze heak net as in net-cachet callback per saakoanfraach foar in wearde dy't by elk oanrop feroarje moat. Kies transporteigendom dêrop oanpast as in accountmarker fariearret.

By gewoane HTTP-trochstjoering hawwe proxy-fjilden noch it bedoelde konsumpsjebelied fan it tuskenstasjon nedich. Dat in header proxy-spesifyk is yn 'e kliïnt-API is gjin garânsje foar fertroulikens as de proxy him trochstjoert.