Vir 'n opskrif wat deur die proxy-operateur bepaal word, bied Requests HTTPAdapter.proxy_headers as 'n oorheersingspunt:

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 'n voorbeeld van 'n veld wat hierdie spesifieke proxy verstaan, nie 'n standaardmanier om by elke tussenganger te verifieer nie.

Begin met super().proxy_headers(proxy). Requests gebruik daardie metode om Proxy-Authorization te genereer wanneer die URL 'n Basic-rekening verskaf. Om die hele resultaat te vervang kan daardie gedrag laat verlore gaan.

Die adapter gee hierdie waardes aan urllib3 se ProxyManager. Vir 'n HTTPS-tonnel vergesel hulle CONNECT. Die gewone versoek-opskrifte-mapping beskryf die latere versoek na die bestemming.

Proxy-bestuurders word per proxy-URL gekas. Moenie hierdie haak as 'n ongekaste callback per besigheidsversoek behandel vir 'n waarde wat by elke oproep moet verander nie. Kies transport-eienaarskap dienooreenkomstig wanneer 'n rekeningmerker wissel.

Vir gewone HTTP-aanstuur benodig proxy-velde steeds die tussenganger se bedoelde verbruiksbeleid. Dat 'n opskrif proxy-spesifiek in die kliënt-API is, waarborg nie vertroulikheid as die proxy dit verder aanstuur nie.

Verwante artikels