प्रॉक्सी ऑपरेटर द्वारा परिभाषित हेडर के लिए 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 में हेडर का प्रॉक्सी-विशिष्ट होना गोपनीयता की गारंटी नहीं है, यदि प्रॉक्सी उसे आगे भेज देता है।

संबंधित लेख