Set proxy-hovud med HTTPAdapter.proxy_headers i Requests
Utvid HTTPAdapter.proxy_headers for eit proxydefinert felt, medan den eksisterande genereringa av proxy-autentiseringshovud i Requests blir halden.
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.