اگر یک opener در urllib باید مستقیم متصل شود، یک نگاشت خالی به ProxyHandler بدهید:

from urllib.request import ProxyHandler, build_opener

direct = build_opener(ProxyHandler({}))

with direct.open("https://example.com/", timeout=10) as response:
    print(response.status)

دیکشنری خالی هیچ مسیر پراکسی‌ای ارائه نمی‌کند. حذف نگاشت در عوض به handler اجازه می‌دهد پراکسی‌ها را از محیط و تنظیمات پلتفرم کشف کند. این دو شیوهٔ ساخت، سیاست‌های متفاوتی را بیان می‌کنند.

مثال از کتابخانهٔ استاندارد Python استفاده می‌کند و بررسی عادی HTTPS را حفظ می‌کند. بلوک with پاسخ را می‌بندد، حتی وقتی استثنا باعث خروج از بلوک شود.

درخواست‌های مستقیم و پراکسی‌شده در یک برنامه

دو opener می‌توانند دو سیاست را اجرا کنند، بدون اینکه متغیرهای محیطی بین فراخوانی‌ها تغییر کنند:

from urllib.request import ProxyHandler, build_opener

direct = build_opener(ProxyHandler({}))
proxied = build_opener(ProxyHandler({
    "http": "http://127.0.0.1:8080",
    "https": "http://127.0.0.1:8080",
}))

with proxied.open("https://example.com/", timeout=10) as response:
    print(response.status)

نشانی loopback را با پراکسی HTTP خود جایگزین کنید یا برای مقایسهٔ اتصال پراکسی‌شده از فهرست پراکسی‌های HTTP گزینه‌ای انتخاب کنید. اگر سرویس اجازه دهد، می‌تواند اتصال به مقصد HTTPS را از طریق CONNECT عبور دهد. پروتکل و پشتیبانی احراز هویت شنونده باید با handler سازگار باشند.

opener پیش‌فرض را تغییر ندهید

direct.open یا proxied.open را از طریق شیئی فراخوانی کنید که مسئول مسیر است. install_opener پیش‌فرض سراسری فرایند را که توابع تسهیل‌کنندهٔ urllib استفاده می‌کنند تغییر می‌دهد؛ بنابراین کتابخانه‌ای که از آن استفاده کند می‌تواند بر کد نامرتبط اثر بگذارد. برای opener جداگانهٔ بالا نیازی به آن نیست.

آرگومان timeout تنظیم یک عملیات است، نه مهلت کامل بر اساس زمان واقعی برای هر انتقال. فقط داده‌های لازم را بخوانید و اگر کار محدودیت سختی برای کل زمان دارد، از مهلتی در سطح بالاتر استفاده کنید.

این اشیای opener کلاینت کتابخانه‌ای دیگر، فرایندی موجود یا تنظیمات پراکسی مرورگر را تغییر نمی‌دهند.

مقالات مرتبط