For eit hovud som proxyoperatøren definerer, tilbyr Requests HTTPAdapter.proxy_headers som overstyringspunkt:

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 er eit døme på eit felt som nettopp denne proxyen forstår, ikkje ein standard måte å autentisere seg mot kvar mellomledd.

Start med super().proxy_headers(proxy). Requests brukar den metoden til å generere Proxy-Authorization når URL-en gjev ein Basic-konto. Å byta ut heile resultatet kan mista denne åtferda.

Adapteren sender desse verdiane vidare til ProxyManager i urllib3. I ein HTTPS-tunnel følgjer dei med CONNECT. Den vanlege hovudtilordninga for førespurnaden skildrar den seinare førespurnaden til målet.

Proxy-handsamarar blir bufra per proxy-URL. Ikkje handsam denne kroken som ein ubufra tilbakeringing per forretningsførespurnad for ein verdi som må endrast ved kvart kall. Vel transporteigaransvar deretter når ein kontomerkje varierer.

Ved vanleg HTTP-vidaresending treng proxy-felt framleis den tiltenkte brukspolitikken til mellomleddet. At eit hovud er proxyspesifikt i klient-API-et er inga garanti for konfidensialitet om proxyen sender det vidare.

Relaterte artiklar