ప్రాక్సీ ఆపరేటర్ నిర్ణయించిన హెడర్ కోసం, Requests HTTPAdapter.proxy_headers ను ఓవర్‌రైడ్ పాయింట్‌గా అందిస్తుంది:

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 ఈ నిర్దిష్ట ప్రాక్సీ అర్థం చేసుకునే ఫీల్డ్‌కు ఉదాహరణ, ప్రతి మధ్యవర్తితో ప్రామాణీకరణకు ప్రామాణిక మార్గం కాదు.

super().proxy_headers(proxy) తో ప్రారంభించండి. URL Basic ఖాతాను ఇచ్చినప్పుడు Requests ఆ పద్ధతిని ఉపయోగించి Proxy-Authorization సృష్టిస్తుంది. మొత్తం ఫలితాన్ని భర్తీ చేయడం ఆ ప్రవర్తనను కోల్పోవచ్చు.

అడాప్టర్ ఈ విలువలను urllib3 యొక్క ProxyManager కు పంపుతుంది. HTTPS సొరంగంలో అవి CONNECT తో పాటు వెళ్తాయి. సాధారణ అభ్యర్థన-హెడర్ మ్యాపింగ్ తర్వాతి గమ్యస్థాన అభ్యర్థనను వివరిస్తుంది.

ప్రాక్సీ మేనేజర్లు ప్రాక్సీ URL ప్రకారం కాష్ చేయబడతాయి. ప్రతి కాల్‌లో మారాల్సిన విలువ కోసం ఈ హుక్‌ను కాష్ లేని ప్రతి-వ్యాపార-అభ్యర్థన కాల్‌బ్యాక్‌గా పరిగణించవద్దు. ఖాతా మార్కర్ మారినప్పుడు దానికి అనుగుణంగా రవాణా యాజమాన్యాన్ని ఎంచుకోండి.

సాధారణ HTTP ఫార్వర్డింగ్‌లో ప్రాక్సీ ఫీల్డ్‌లకు ఇప్పటికీ మధ్యవర్తి ఉద్దేశించిన వినియోగ విధానం అవసరం. క్లయింట్ API లో హెడర్ ప్రాక్సీ-నిర్దిష్టంగా ఉండటం ప్రాక్సీ దానిని ముందుకు పంపితే గోప్యతకు హామీ కాదు.

సంబంధిత వ్యాసాలు