Kwa kichwa kinachobainishwa na mwendeshaji wa proksi, Requests hutoa HTTPAdapter.proxy_headers kama mahali pa kubatilisha:

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 ni mfano wa uga unaoeleweka na proksi hii mahususi, si njia ya kawaida ya kuthibitisha kwa kila mpatanishi.

Anza na super().proxy_headers(proxy). Requests hutumia mbinu hiyo kutengeneza Proxy-Authorization wakati URL inatoa akaunti ya Basic. Kubadilisha matokeo yote kunaweza kupoteza tabia hiyo.

Adapta hupitisha thamani hizi kwa ProxyManager ya urllib3. Katika handaki la HTTPS huandamana na CONNECT. Uwekaji ramani wa kawaida wa vichwa vya ombi hueleza ombi la baadaye kwa lengo.

Wasimamizi wa proksi huhifadhiwa kwenye akiba kwa URL ya proksi. Usichukulie ndoano hii kama mwitikio usiohifadhiwa kwa kila ombi la biashara kwa thamani inayopaswa kubadilika katika kila mwito. Chagua umiliki wa usafirishaji kwa kadiri hiyo wakati alama ya akaunti inapotofautiana.

Katika uelekezaji wa kawaida wa HTTP, sehemu za proksi bado zinahitaji sera ya matumizi inayokusudiwa na mpatanishi. Kichwa kuwa maalum kwa proksi katika API ya mteja si dhamana ya usiri ikiwa proksi itakisambaza.

Makala zinazohusiana