प्रोक्सी अपरेटरले परिभाषित गरेको हेडरका लागि 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 मा हेडर प्रोक्सी-विशिष्ट हुनु गोपनीयताको ग्यारेन्टी होइन यदि प्रोक्सीले त्यसलाई अगाडि पठाउँछ।

सम्बन्धित लेखहरू