Налаштування заголовків проксі за допомогою HTTPAdapter.proxy_headers у Requests

Для заголовка, який визначає оператор проксі, 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). Requests використовує цей метод для створення Proxy-Authorization, коли URL містить обліковий запис Basic. Заміна всього результату може позбавити цієї поведінки.

Адаптер передає ці значення до ProxyManager з urllib3. У тунелі HTTPS вони супроводжують CONNECT. Звичайне зіставлення заголовків запиту описує наступний запит до призначення.

Менеджери проксі кешуються за URL проксі. Не розглядайте цей хук як некшейований зворотний виклик на кожен бізнес-запит для значення, яке має змінюватися при кожному виклику. Обирайте власника транспорту відповідно, коли позначка облікового запису змінюється.

Під час звичайного пересилання HTTP полям проксі все ще потрібна передбачувана політика споживання посередника. Те, що заголовок є специфічним для проксі в клієнтському API, не гарантує конфіденційності, якщо проксі передає його далі.