Requests च्या HTTPAdapter.proxy_headers सह प्रॉक्सी हेडर सेट करणे

प्रॉक्सी ऑपरेटरने ठरवलेल्या हेडरसाठी 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 मध्ये हेडर प्रॉक्सी-विशिष्ट असणे गोपनीयतेची हमी नाही, जर प्रॉक्सी ते पुढे पाठवत असेल.