Për një kokë të përcaktuar nga operatori i proxy-t, Requests ekspozon HTTPAdapter.proxy_headers si pikë mbivendosjeje:

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 është shembull i një fushe që e kupton pikërisht ky proxy, jo një mënyrë standarde për t'u vërtetuar ndaj çdo ndërmjetësi.

Filloni me super().proxy_headers(proxy). Requests e përdor atë metodë për të gjeneruar Proxy-Authorization kur URL-ja ofron një llogari Basic. Zëvendësimi i të gjithë rezultatit mund ta humbasë atë sjellje.

Përshtatësi i kalon këto vlera te ProxyManager i urllib3. Në një tunel HTTPS ato shoqërojnë CONNECT. Hartëzimi i zakonshëm i kokave të kërkesës përshkruan kërkesën e mëvonshme drejt destinacionit.

Menaxherët e proxy-t ruhen në cache sipas URL-së së proxy-t. Mos e trajtoni këtë grep si një kthim thirrjeje pa cache për çdo kërkesë biznesi për një vlerë që duhet të ndryshojë në çdo thirrje. Zgjidhni pronësinë e transportit në përputhje kur shenja e llogarisë ndryshon.

Në përcjelljen e thjeshtë HTTP, fushat e proxy-t ende kanë nevojë për politikën e synuar të konsumit të ndërmjetësit. Fakti që një kokë është specifike për proxy-n në API-n e klientit nuk është garanci konfidencialiteti nëse proxy-i e përcjell më tej.

Artikuj të ngjashëm