پراکسی آپریٹر کی متعین کردہ ہیڈر کے لیے 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 میں ہیڈر کا پراکسی کے لیے مخصوص ہونا رازداری کی ضمانت نہیں اگر پراکسی اسے آگے بھیج دے۔

متعلقہ مضامین