`urllib.request` --- کتابخانه‌ی گسترش‌پذیر برای باز کردن URLها¶

کد منبع: Lib/urllib/request.py

ماژول urllib.request توابع و کلاس‌هایی را تعریف می‌کند که به باز کردن URLها (عمدتاً HTTP) در دنیایی پیچیده کمک می‌کنند — احراز هویت پایه (basic authentication) و احراز هویت digest (digest authentication)، تغییرمسیرها، کوکی‌ها و موارد دیگر.

همچنین ملاحظه نمائید

بسته‌ی Requests برای یک رابط کلاینت HTTP سطح بالاتر توصیه می‌شود.

هشدار

در macOS استفاده از این ماژول در برنامه‌هایی که از os.fork() استفاده می‌کنند امن نیست، زیرا پیاده‌سازی getproxies() برای macOS از یک API سیستمی سطح بالاتر استفاده می‌کند. برای اجتناب از این مشکل، متغیر محیطی no_proxy را روی * تنظیم کنید (برای مثال os.environ["no_proxy"] = "*").

دسترس‌پذیری: not WASI.

این ماژول روی WebAssembly کار نمی‌کند یا در دسترس نیست. برای اطلاعات بیشتر سکوهای WebAssembly را ببینید.

ماژول urllib.request توابع زیر را تعریف می‌کند:

urllib.request.urlopen(url, data=None, [timeout, ]*, context=None)¶

url را باز می‌کند، که می‌تواند یا یک رشته حاوی یک URL معتبر و به‌درستی کدگذاری‌شده باشد یا یک شیء Request.

data باید شیءای باشد که داده‌های اضافی برای ارسال به سرور را مشخص می‌کند، یا اگر نیازی به چنین داده‌ای نیست None باشد. برای جزئیات Request را ببینید.

ماژول urllib.request از HTTP/1.1 استفاده می‌کند و سرآیند Connection:close را در درخواست‌های HTTP خود قرار می‌دهد.

پارامتر اختیاری timeout یک مهلت زمانی بر حسب ثانیه برای عملیات‌های مسدودکننده مانند تلاش برای اتصال مشخص می‌کند (اگر مشخص نشده باشد، از تنظیم مهلت زمانی پیش‌فرض سراسری استفاده می‌شود). این در واقع فقط برای اتصال‌های HTTP، HTTPS و FTP کار می‌کند.

اگر context مشخص شده باشد، باید نمونه‌ای از ssl.SSLContext باشد که گزینه‌های مختلف SSL را توصیف می‌کند. برای جزئیات بیشتر، HTTPSConnection را ببینید.

این تابع همواره شیءای را برمی‌گرداند که می‌تواند به‌عنوان یک context manager عمل کند و دارای ویژگی‌های url، headers و status است. برای جزئیات بیشتر در مورد این ویژگی‌ها، urllib.response.addinfourl را ببینید.

برای URLهای HTTP و HTTPS، این تابع یک شیء http.client.HTTPResponse را با کمی تغییر برمی‌گرداند. علاوه بر ۳ متد جدید بالا، ویژگی msg به‌جای سرآیندهای پاسخ، همان‌طور که در مستندات HTTPResponse مشخص شده است، حاوی همان اطلاعاتی است که ویژگی reason دارد — عبارت دلیلی که سرور آن را برمی‌گرداند.

برای URLهای FTP، file و data، این تابع یک شیء urllib.response.addinfourl را برمی‌گرداند.

در صورت بروز خطاهای پروتکل، URLError پرتاب می‌شود.

توجه داشته باشید که اگر هیچ هندلری درخواست را مدیریت نکند، ممکن است None برگردانده شود (هرچند OpenerDirector سراسری که به‌صورت پیش‌فرض نصب شده است، از UnknownHandler استفاده می‌کند تا اطمینان حاصل کند که این حالت هرگز رخ نمی‌دهد).

علاوه بر این، اگر تنظیمات پراکسی شناسایی شوند (برای مثال، زمانی که یک متغیر محیطی *_proxy مانند http_proxy تنظیم شده باشد)، ProxyHandler به‌طور پیش‌فرض نصب می‌شود و اطمینان حاصل می‌کند که درخواست‌ها از طریق پراکسی مدیریت می‌شوند.

تابع قدیمی urllib.urlopen مربوط به پایتون 2.6 و نسخه‌های قدیمی‌تر از رده خارج شده است؛ urllib.request.urlopen() معادل urllib2.urlopen قدیمی است. مدیریت پراکسی، که با ارسال یک پارامتر دیکشنری به urllib.urlopen انجام می‌شد، با استفاده از اشیای ProxyHandler امکان‌پذیر است.

بازکننده پیش‌فرض (opener) یک رویداد حسابرسی urllib.Request را با آرگومان‌های fullurl، data، headers و method گرفته‌شده از شیء درخواست پرتاب می‌کند.

تغییر یافته در نسخه‌ی 3.2: cafile و capath افزوده شدند.

اکنون میزبان‌های مجازی HTTPS در صورت امکان (یعنی اگر ssl.HAS_SNI درست باشد) پشتیبانی می‌شوند.

data می‌تواند یک شیء پیمایش‌پذیر باشد.

تغییر یافته در نسخه‌ی 3.3: cadefault افزوده شد.

تغییر یافته در نسخه‌ی 3.4.3: context اضافه شد.

تغییر یافته در نسخه‌ی 3.10: اتصال HTTPS اکنون هنگامی که context داده نشده باشد، یک افزونه ALPN با نشانگر پروتکل http/1.1 ارسال می‌کند. یک context سفارشی باید پروتکل‌های ALPN را با set_alpn_protocols() تنظیم کند.

تغییر یافته در نسخه‌ی 3.13: پارامترهای cafile، capath و cadefault را حذف کنید: به‌جای آن‌ها از پارامتر context استفاده کنید.

urllib.request.install_opener(opener)¶: نمونه‌ای از OpenerDirector را به‌عنوان بازکننده‌ی سراسری پیش‌فرض نصب کنید. نصب یک بازکننده تنها در صورتی لازم است که بخواهید urlopen از آن بازکننده استفاده کند؛ در غیر این صورت، به‌سادگی OpenerDirector.open() را به‌جای urlopen() فراخوانی کنید. این کد بررسی نمی‌کند که یک OpenerDirector واقعی باشد، و هر کلاسی با رابط مناسب کار خواهد کرد.

urllib.request.build_opener([handler, ...])¶

نمونه‌ای از OpenerDirector برمی‌گرداند، که handlerها را به ترتیب داده‌شده به هم زنجیره می‌کند. handlers می‌توانند نمونه‌هایی از BaseHandler یا زیرکلاس‌هایی از BaseHandler باشند (که در این صورت باید بتوان سازنده را بدون هیچ پارامتری فراخوانی کرد). نمونه‌هایی از کلاس‌های زیر پیش از handlers قرار می‌گیرند، مگر آنکه handlers شامل آن‌ها، نمونه‌هایی از آن‌ها یا زیرکلاس‌هایی از آن‌ها باشند: ProxyHandler (اگر تنظیمات پراکسی تشخیص داده شود)، UnknownHandler، HTTPHandler، HTTPDefaultErrorHandler، HTTPRedirectHandler، FTPHandler، FileHandler، HTTPErrorProcessor.

اگر نصب پایتون از SSL پشتیبانی کند (یعنی اگر بتوان ماژول ssl را ایمپورت کرد)، HTTPSHandler نیز افزوده خواهد شد.

یک زیرکلاس از BaseHandler همچنین می‌تواند با تغییر ویژگی handler_order خود، جایگاه خود را در فهرست هندلرها تغییر دهد.

urllib.request.pathname2url(path, *, add_scheme=False)¶

مسیر محلی داده‌شده را به یک URL file: تبدیل می‌کند. این تابع برای کدگذاری مسیر از تابع quote() استفاده می‌کند.

اگر add_scheme نادرست باشد (پیش‌فرض)، مقدار بازگشتی فاقد پیشوند طرح‌واره‌ی file: است. برای بازگرداندن یک URL کامل، add_scheme را روی درست تنظیم کنید.

این مثال استفاده از تابع در ویندوز را نشان می‌دهد:

>>> from urllib.request import pathname2url
>>> path = 'C:\\Program Files'
>>> pathname2url(path, add_scheme=True)
'file:///C:/Program%20Files'

تغییر یافته در نسخه‌ی 3.14: حروف درایو ویندوز دیگر به حروف بزرگ تبدیل نمی‌شوند، و نویسه‌های : که پس از حرف درایو نیایند دیگر باعث پرتاب شدن استثنای OSError در ویندوز نمی‌شوند.

تغییر یافته در نسخه‌ی 3.14: مسیرهایی که با اسلش آغاز می‌شوند، به URLهایی با بخش‌های authority تبدیل می‌شوند. برای مثال، مسیر /etc/hosts به URL ///etc/hosts تبدیل می‌شود.

تغییر یافته در نسخه‌ی 3.14: پارامتر add_scheme افزوده شد.

urllib.request.url2pathname(url, *, require_scheme=False, resolve_host=False)¶

URL file: داده‌شده را به یک مسیر محلی تبدیل می‌کند. این تابع از unquote() برای کدگشایی URL استفاده می‌کند.

اگر require_scheme نادرست باشد (پیش‌فرض)، مقدار داده‌شده باید فاقد پیشوند طرح‌واره file: باشد. اگر require_scheme روی درست تنظیم شده باشد، مقدار داده‌شده باید شامل این پیشوند باشد؛ در غیر این صورت یک URLError پرتاب می‌شود.

اگر authority نشانی URL خالی، localhost یا نام میزبان محلی باشد، از آن چشم‌پوشی می‌شود. در غیر این صورت، اگر resolve_host روی true تنظیم شده باشد، authority با استفاده از socket.gethostbyname() حل می‌شود و در صورت تطابق با یک نشانی IP محلی از آن چشم‌پوشی می‌شود (طبق RFC 8089 §3). اگر authority همچنان بدون رسیدگی باقی بماند، سپس در ویندوز یک مسیر UNC برگردانده می‌شود و در سایر سکوها یک URLError پرتاب می‌شود.

این مثال استفاده از تابع در ویندوز را نشان می‌دهد:

>>> from urllib.request import url2pathname
>>> url = 'file:///C:/Program%20Files'
>>> url2pathname(url, require_scheme=True)
'C:\\Program Files'

تغییر یافته در نسخه‌ی 3.14: حروف درایو ویندوز دیگر به حروف بزرگ تبدیل نمی‌شوند، و نویسه‌های : که پس از حرف درایو نیایند دیگر باعث پرتاب شدن استثنای OSError در ویندوز نمی‌شوند.

تغییر یافته در نسخه‌ی 3.14: اگر مرجع URL (authority) با نام میزبان محلی مطابقت داشته باشد، حذف می‌شود. در غیر این صورت، اگر مرجع خالی یا localhost نباشد، در ویندوز یک مسیر UNC برگردانده می‌شود (مانند قبل)، و در سایر پلتفرم‌ها یک URLError پرتاب می‌شود.

تغییر یافته در نسخه‌ی 3.14: کامپوننت‌های query و fragmentِ URL، در صورت وجود، حذف می‌شوند.

تغییر یافته در نسخه‌ی 3.14: پارامترهای require_scheme و resolve_host افزوده شدند.

urllib.request.getproxies()¶: این تابع کمکی، دیکشنری از نگاشت‌های طرح‌واره به URL سرور پراکسی را برمی‌گرداند. این تابع ابتدا محیط را در همه‌ی سیستم‌عامل‌ها برای یافتن متغیرهایی با نام <scheme>_proxy به‌صورت غیرحساس به حروف کوچک و بزرگ بررسی می‌کند و اگر آن‌ها را پیدا نکند، اطلاعات پراکسی را از System Configuration برای macOS و Windows Systems Registry برای Windows جستجو می‌کند. اگر هر دو متغیر محیطی با حروف کوچک و بزرگ وجود داشته باشند (و با هم مغایرت داشته باشند)، متغیر با حروف کوچک ترجیح داده می‌شود.

توجه

اگر متغیر محیطی REQUEST_METHOD تنظیم شده باشد، که معمولاً نشان می‌دهد اسکریپت شما در یک محیط CGI در حال اجرا است، متغیر محیطی HTTP_PROXY (_PROXY با حروف بزرگ) نادیده گرفته می‌شود. دلیل این امر آن است که این متغیر می‌تواند توسط یک کلاینت با استفاده از سرآیند HTTP با نام "Proxy:" تزریق شود. اگر نیاز دارید در یک محیط CGI از پراکسی HTTP استفاده کنید، یا به‌صراحت از ProxyHandler استفاده کنید، یا اطمینان حاصل کنید که نام متغیر با حروف کوچک است (یا حداقل پسوند _proxy با حروف کوچک باشد).

کلاس‌های زیر ارائه شده‌اند:

class urllib.request.Request(url, data=None, headers={}, origin_req_host=None, unverifiable=False, method=None)¶

این کلاس انتزاعی از یک درخواست URL است.

url باید رشته‌ای حاوی یک URL معتبر و به‌درستی کدگذاری‌شده باشد.

data باید شیءای باشد که داده‌های اضافی برای ارسال به سرور را مشخص می‌کند، یا اگر نیازی به چنین داده‌ای نیست، None باشد. در حال حاضر، تنها درخواست‌های HTTP هستند که از data استفاده می‌کنند. انواع شیء پشتیبانی‌شده شامل بایت‌ها، اشیاء شبه‌پرونده و اشیاء پیمایش‌پذیر از اشیاء شبه‌بایت هستند. اگر هیچ فیلد سرآیند Content-Length یا Transfer-Encoding ارائه نشده باشد، HTTPHandler این سرآیندها را با توجه به نوع data تنظیم می‌کند. برای ارسال اشیاء بایتی از Content-Length استفاده می‌شود، در حالی که برای ارسال پرونده‌ها و سایر اشیاء پیمایش‌پذیر از Transfer-Encoding: chunked، همان‌طور که در RFC 7230، بخش 3.3.1 مشخص شده است، استفاده خواهد شد.

برای روش درخواست HTTP POST، data باید یک بافر در قالب استاندارد application/x-www-form-urlencoded باشد. تابع urllib.parse.urlencode() یک نگاشت یا دنباله‌ای از تاپل‌های دوتایی را دریافت می‌کند و یک رشته ASCII در این قالب برمی‌گرداند. این مقدار باید پیش از استفاده به‌عنوان پارامتر data به بایت‌ها کدگذاری شود.

headers باید یک دیکشنری باشد، و به‌گونه‌ای با آن رفتار خواهد شد که گویی add_header() با هر کلید و مقدار به‌عنوان آرگومان فراخوانی شده باشد. این کار اغلب برای «جعل» مقدار سرآیند User-Agent به کار می‌رود، که مرورگر برای شناسایی خود از آن استفاده می‌کند — برخی سرورهای HTTP فقط درخواست‌هایی را می‌پذیرند که از مرورگرهای رایج آمده باشند، نه از اسکریپت‌ها. برای مثال، ممکن است Mozilla Firefox خود را به‌صورت "Mozilla/5.0 (X11; U; Linux i686) Gecko/20071127 Firefox/2.0.0.11" شناسایی کند، در حالی که رشته‌ی عامل کاربر پیش‌فرض urllib برابر "Python-urllib/2.6" است (در Python 2.6). همه‌ی کلیدهای سرآیند به‌صورت حالت شتری (camel case) ارسال می‌شوند.

اگر آرگومان data وجود داشته باشد، باید یک سرآیند Content-Type مناسب درج شود. اگر این سرآیند ارائه نشده باشد و data برابر None نباشد، Content-Type: application/x-www-form-urlencoded به‌عنوان پیش‌فرض اضافه خواهد شد.

دو آرگومان بعدی فقط برای مدیریت صحیح کوکی‌های HTTP شخص ثالث اهمیت دارند:

origin_req_host باید میزبان درخواست (request-host) تراکنش مبدأ باشد، همان‌طور که در RFC 2965 تعریف شده است. مقدار پیش‌فرض آن http.cookiejar.request_host(self) است. این مقدار، نام میزبان یا نشانی IP درخواست اصلی‌ای است که توسط کاربر آغاز شده است. برای مثال، اگر درخواست برای تصویری در یک سند HTML باشد، این باید request-host مربوط به درخواست برای صفحه‌ای باشد که تصویر در آن قرار دارد.

unverifiable باید نشان دهد که آیا درخواست غیرقابل‌تأیید است، همان‌طور که در RFC 2965 تعریف شده است. مقدار پیش‌فرض آن False است. درخواست غیرقابل‌تأیید درخواستی است که کاربر امکان تأیید URL آن را نداشته است. برای مثال، اگر درخواست برای یک تصویر در یک سند HTML باشد و کاربر امکان تأیید واکشی خودکار تصویر را نداشته باشد، این مقدار باید درست باشد.

method باید رشته‌ای باشد که متد درخواست HTTP مورد استفاده را مشخص می‌کند (برای مثال 'HEAD'). در صورت ارائه، مقدار آن در ویژگی method ذخیره می‌شود و get_method() از آن استفاده می‌کند. مقدار پیش‌فرض، اگر data برابر None باشد 'GET' و در غیر این صورت 'POST' است. زیرکلاس‌ها می‌توانند با تنظیم ویژگی method در خود کلاس، متد پیش‌فرض متفاوتی را مشخص کنند.

توجه

اگر شیء داده نتواند محتوای خود را بیش از یک بار تحویل دهد (برای نمونه یک پرونده یا یک پیمایش‌پذیر که فقط می‌تواند محتوا را یک بار تولید کند) و درخواست به‌دلیل تغییرمسیرهای HTTP یا احراز هویت دوباره تلاش شود، درخواست آن‌طور که انتظار می‌رود کار نخواهد کرد. data بلافاصله پس از سرآیند‌ها به سرور HTTP ارسال می‌شود. در این کتابخانه، از انتظار 100-continue پشتیبانی نمی‌شود.

تغییر یافته در نسخه‌ی 3.3: آرگومان Request.method به کلاس Request اضافه شده است.

تغییر یافته در نسخه‌ی 3.4: مقدار پیش‌فرض Request.method را می‌توان در سطح کلاس مشخص کرد.

تغییر یافته در نسخه‌ی 3.6: اگر Content-Length ارائه‌نشده باشد و data نه None و نه یک شیء bytes باشد، خطایی پرتاب نکنید. در عوض، به‌عنوان جایگزین از کدگذاری انتقال تکه‌ای (chunked transfer encoding) استفاده کنید.

class urllib.request.OpenerDirector¶: کلاس OpenerDirector نشانی‌های URL را از طریق BaseHandlerهایی که به یکدیگر زنجیر شده‌اند باز می‌کند. این کلاس زنجیره‌سازی هندلرها و بازیابی از خطاها را مدیریت می‌کند.

class urllib.request.BaseHandler¶: این کلاس پایه برای تمام هندلرهای ثبت‌شده است --- و فقط سازوکار ساده‌ی ثبت را مدیریت می‌کند.

class urllib.request.HTTPDefaultErrorHandler¶: کلاسی که یک هندلر پیش‌فرض برای پاسخ‌های خطای HTTP تعریف می‌کند؛ تمام پاسخ‌ها به استثناهای HTTPError تبدیل می‌شوند.

class urllib.request.HTTPRedirectHandler¶: کلاسی برای مدیریت تغییرمسیرها.

class urllib.request.HTTPCookieProcessor(cookiejar=None)¶: کلاسی برای مدیریت کوکی‌های HTTP.

class urllib.request.ProxyHandler(proxies=None)¶

سبب می‌شود درخواست‌ها از طریق یک پراکسی عبور کنند. اگر proxies داده شود، باید دیکشنری‌ای باشد که نام پروتکل‌ها را به URLهای پراکسی‌ها نگاشت می‌کند. حالت پیش‌فرض، خواندن فهرست پراکسی‌ها از متغیرهای محیطی <protocol>_proxy است. اگر هیچ متغیر محیطی پراکسی تنظیم نشده باشد، در محیط ویندوز تنظیمات پراکسی از بخش Internet Settings در رجیستری به دست می‌آید و در محیط macOS اطلاعات پراکسی از System Configuration Framework بازیابی می‌شود.

برای غیرفعال کردن پراکسی تشخیص‌داده‌شده به‌صورت خودکار، یک دیکشنری خالی ارسال کنید.

از متغیر محیطی no_proxy می‌توان برای مشخص کردن میزبان‌هایی استفاده کرد که نباید از طریق پراکسی به آن‌ها دسترسی پیدا کرد؛ اگر تنظیم شده باشد، باید فهرستی جداشده با کاما از پسوندهای نام میزبان باشد که به‌اختیار :port به آن‌ها افزوده شده است، برای مثال cern.ch,ncsa.uiuc.edu,some.host:8080.

توجه

اگر متغیر REQUEST_METHOD تنظیم شده باشد، از HTTP_PROXY چشم‌پوشی می‌شود؛ به مستندات getproxies() مراجعه کنید.

class urllib.request.HTTPPasswordMgr¶: یک پایگاه داده از نگاشت‌های (realm, uri) -> (user, password) نگهداری کنید.

class urllib.request.HTTPPasswordMgrWithDefaultRealm¶: پایگاه داده‌ای از نگاشت‌های (realm, uri) -> (user, password) را نگه می‌دارد. یک قلمرو (realm) با مقدار None به‌عنوان یک قلمرو همه‌گیر (catch-all realm) در نظر گرفته می‌شود، که اگر هیچ قلمرو دیگری منطبق نباشد، جستجو می‌شود.

class urllib.request.HTTPPasswordMgrWithPriorAuth¶: گونه‌ای از HTTPPasswordMgrWithDefaultRealm که همچنین پایگاه داده‌ای از نگاشت‌های uri -> is_authenticated دارد. یک هندلری BasicAuth می‌تواند از آن برای تعیین زمان ارسال فوری اعتبارنامه‌های احراز هویت، به‌جای اینکه ابتدا منتظر پاسخ 401 بماند، استفاده کند.

اضافه شده در نسخه‌ی 3.5.

class urllib.request.AbstractBasicAuthHandler(password_mgr=None)¶: این یک کلاس میکس‌این است که به احراز هویت HTTP کمک می‌کند، هم برای میزبان راه‌دور و هم برای پراکسی. password_mgr، در صورت ارائه، باید با HTTPPasswordMgr سازگار باشد؛ برای اطلاعات درباره‌ی رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید. اگر passwd_mgr همچنین متدهای is_authenticated و update_authenticated را فراهم کند (به اشیاء HTTPPasswordMgrWithPriorAuth مراجعه کنید)، آنگاه هندلر از نتیجه‌ی is_authenticated برای یک URI مشخص استفاده می‌کند تا تعیین کند که آیا اعتبارنامه‌های احراز هویت همراه با درخواست ارسال شوند یا خیر. اگر is_authenticated برای آن URI مقدار True را برگرداند، اعتبارنامه‌ها ارسال می‌شوند. اگر is_authenticated برابر False باشد، اعتبارنامه‌ها ارسال نمی‌شوند، و سپس اگر پاسخ 401 دریافت شود، درخواست دوباره با اعتبارنامه‌های احراز هویت ارسال می‌شود. اگر احراز هویت موفق شود، update_authenticated فراخوانی می‌شود تا is_authenticated را برای آن URI روی True تنظیم کند، به‌طوری‌که درخواست‌های بعدی به آن URI یا هر یک از ابر-URIهای آن (super-URIs) به‌طور خودکار شامل اعتبارنامه‌های احراز هویت شوند.

اضافه شده در نسخه‌ی 3.5: پشتیبانی از is_authenticated اضافه شد.

class urllib.request.HTTPBasicAuthHandler(password_mgr=None)¶: احراز هویت با میزبان راه دور را مدیریت می‌کند. password_mgr، در صورت ارائه، باید با HTTPPasswordMgr سازگار باشد؛ برای اطلاعات درباره رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید. HTTPBasicAuthHandler در صورت مواجهه با طرح احراز هویت نادرست، یک ValueError پرتاب می‌کند.

class urllib.request.ProxyBasicAuthHandler(password_mgr=None)¶: احراز هویت با پراکسی را مدیریت می‌کند. password_mgr، اگر داده شود، باید با HTTPPasswordMgr سازگار باشد؛ برای اطلاعات درباره‌ی رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید.

class urllib.request.AbstractDigestAuthHandler(password_mgr=None)¶: این یک کلاس میکس‌این است که به احراز هویت HTTP، هم برای میزThis is a mixin class that helps with HTTP authenticationبان دوردست و هم برای پراکسی، کمک می‌کند. password_mgr، در صورت ارائه، باید چیزی سازگار با HTTPPasswordMgr باشد؛ برای اطلاعات درباره رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید.

تغییر یافته در نسخه‌ی 3.14: پشتیبانی از الگوریتم احراز هویت digest HTTP با SHA-256 افزوده شد.

class urllib.request.HTTPDigestAuthHandler(password_mgr=None)¶: به احراز هویت با میزبان راه دور رسیدگی می‌کند. password_mgr، در صورت ارائه، باید با HTTPPasswordMgr سازگار باشد؛ برای اطلاعات درباره رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید. وقتی هر دو هندلر احراز هویت Digest و Basic اضافه شده باشند، احراز هویت Digest همیشه ابتدا امتحان می‌شود. اگر احراز هویت Digest دوباره پاسخ 40x برگرداند، برای رسیدگی به هندلر احراز هویت Basic فرستاده می‌شود. این متد هندلر در صورت مواجهه با روش احراز هویتی غیر از Digest یا Basic، یک ValueError پرتاب می‌کند.

تغییر یافته در نسخه‌ی 3.3: در صورت طرح‌واره احراز هویت پشتیبانی‌نشده، ValueError پرتاب می‌شود.

class urllib.request.ProxyDigestAuthHandler(password_mgr=None)¶: احراز هویت با پراکسی را مدیریت می‌کند. password_mgr، اگر داده شود، باید با HTTPPasswordMgr سازگار باشد؛ برای اطلاعات درباره‌ی رابطی که باید پشتیبانی شود، به بخش اشیاء HTTPPasswordMgr مراجعه کنید.

class urllib.request.HTTPHandler¶: کلاسی برای رسیدگی به باز کردن URLهای HTTP.

class urllib.request.HTTPSHandler(debuglevel=0, context=None, check_hostname=None)¶: کلاسی برای رسیدگی به باز کردن URLهای HTTPS. context و check_hostname همان معنایی را دارند که در http.client.HTTPSConnection دارند.

تغییر یافته در نسخه‌ی 3.2: context و check_hostname افزوده شدند.

class urllib.request.FileHandler¶: پرونده‌های محلی را باز کنید.

class urllib.request.DataHandler¶: باز کردن URLهای داده.

اضافه شده در نسخه‌ی 3.4.

class urllib.request.FTPHandler¶: باز کردن URLهای FTP.

class urllib.request.CacheFTPHandler¶: URLهای FTP را باز می‌کند و برای به حداقل رساندن تأخیرها، نهانگاهی از اتصال‌های FTP باز را نگه می‌دارد.

class urllib.request.UnknownHandler¶: یک کلاس جامع (catch-all) برای مدیریت URLهای ناشناخته.

class urllib.request.HTTPErrorProcessor¶: پاسخ‌های خطای HTTP را پردازش می‌کند.

اشیای درخواست¶

متدهای زیر رابط عمومی Request را توصیف می‌کنند، بنابراین می‌توان همه‌ی آن‌ها را در زیرکلاس‌ها بازنویسی کرد. همچنین چندین ویژگی عمومی نیز تعریف می‌کند که کلاینت‌ها می‌توانند از آن‌ها برای بررسی درخواست تجزیه‌شده استفاده کنند.

Request.full_url¶

URL اصلی که به سازنده داده شده است.

تغییر یافته در نسخه‌ی 3.4.

Request.full_url یک ویژگی دارای setter، getter و deleter است. دریافت full_url URL اصلی درخواست را همراه با قطعه (fragment)، در صورت وجود، برمی‌گرداند.

Request.type¶: طرح‌واره URI.

Request.host¶: بخش authority در URI، معمولاً یک میزبان است، اما ممکن است شامل یک پورت نیز باشد که با دونقطه جدا شده است.

Request.origin_req_host¶: میزبان اصلی درخواست، بدون پورت.

Request.selector¶: مسیر URI. اگر Request از پراکسی استفاده کند، selector همان URL کاملی خواهد بود که به پراکسی ارسال می‌شود.

Request.data¶: بدنه‌ی موجودیت برای درخواست، یا None اگر مشخص نشده باشد.

تغییر یافته در نسخه‌ی 3.4: تغییر مقدار Request.data اکنون سرآیند "Content-Length" را در صورتی که پیش‌تر تنظیم یا محاسبه شده باشد، حذف می‌کند.

Request.unverifiable¶: بولی، نشان می‌دهد که آیا درخواست همان‌طور که در RFC 2965 تعریف‌شده است، غیرقابل‌تأیید است.

Request.method¶: متد درخواست HTTP برای استفاده. به‌طور پیش‌فرض مقدار آن None است، که به این معناست که get_method() محاسبه‌ی معمول خود را برای متد مورد استفاده انجام خواهد داد. می‌توان مقدار آن را تنظیم کرد (بنابراین محاسبه‌ی پیش‌فرض در get_method() لغو می‌شود)؛ خواه با ارائه‌ی یک مقدار پیش‌فرض با تنظیم آن در سطح کلاس در یک زیرکلاس از Request، خواه با ارسال یک مقدار به سازنده‌ی Request از طریق آرگومان method.

اضافه شده در نسخه‌ی 3.3.

تغییر یافته در نسخه‌ی 3.4: اکنون می‌توان یک مقدار پیش‌فرض را در زیرکلاس‌ها تنظیم کرد؛ پیش‌تر این مقدار فقط از طریق آرگومان سازنده قابل تنظیم بود.

Request.get_method()¶: رشته‌ای را برمی‌گرداند که نشان‌دهنده‌ی متد درخواست HTTP است. اگر Request.method برابر None نباشد، مقدار آن را برمی‌گرداند؛ در غیر این صورت، اگر Request.data برابر None باشد 'GET' و در غیر این صورت 'POST' را برمی‌گرداند. این فقط برای درخواست‌های HTTP معنا دارد.

تغییر یافته در نسخه‌ی 3.3: get_method اکنون مقدار Request.method را در نظر می‌گیرد.

Request.add_header(key, val)¶: سرآیند دیگری به درخواست اضافه کنید. در حال حاضر، سرآیندها توسط همه هندلرها نادیده گرفته می‌شوند، به جز هندلرهای HTTP که در آن‌ها به فهرست سرآیندهای ارسالی به سرور افزوده می‌شوند. توجه داشته باشید که نمی‌تواند بیش از یک سرآیند با نام یکسان وجود داشته باشد، و فراخوانی‌های بعدی، در صورتی که key تداخل داشته باشد، فراخوانی‌های قبلی را بازنویسی می‌کنند. در حال حاضر، این موضوع باعث از دست رفتن عملکرد HTTP نمی‌شود، زیرا همه سرآیندهایی که استفاده از آن‌ها بیش از یک بار معنا دارد، راهی (مختص سرآیند) برای به دست آوردن همان عملکرد با استفاده از تنها یک سرآیند دارند. توجه داشته باشید که سرآیندهایی که با استفاده از این متد اضافه شده‌اند، به درخواست‌های تغییر مسیر داده‌شده نیز افزوده می‌شوند.

Request.add_unredirected_header(key, header)¶: سرآیندی اضافه کنید که به درخواست تغییرمسیرداده‌شده اضافه نخواهد شد.

Request.has_header(header)¶: برمی‌گرداند که آیا نمونه سرآیند نام‌برده را دارد (هم سرآیندهای عادی و هم سرآیندهای بدون تغییر مسیر را بررسی می‌کند).

Request.remove_header(header)¶: سرآیند با نام مشخص‌شده را از نمونه‌ی درخواست حذف می‌کند (هم از سرآیندهای معمولی و هم از سرآیندهای تغییرمسیرنداده).

اضافه شده در نسخه‌ی 3.4.

Request.get_full_url()¶

نشانی اینترنتی (URL) داده‌شده در سازنده را برمی‌گرداند.

تغییر یافته در نسخه‌ی 3.4.

Request.full_url را برمی‌گرداند

Request.set_proxy(host, type)¶: درخواست را با اتصال به یک سرور پراکسی آماده کنید. host و type جایگزین مقادیر متناظر نمونه خواهند شد و انتخابگر نمونه، URL اصلی داده‌شده در سازنده خواهد بود.

Request.get_header(header_name, default=None)¶: مقدار سرآیند داده‌شده را برمی‌گرداند. اگر سرآیند موجود نباشد، مقدار پیش‌فرض را برمی‌گرداند.

Request.header_items()¶: فهرستی از تاپل‌های (header_name, header_value) از سرآیندهای Request برمی‌گرداند.

تغییر یافته در نسخه‌ی 3.4: متدهای درخواست add_data، has_data، get_data، get_type، get_host، get_selector، get_origin_req_host و is_unverifiable که از نسخه 3.3 منسوخ شده بودند، حذف شده‌اند.

اشیای OpenerDirector¶

نمونه‌های OpenerDirector متدهای زیر را دارند:

OpenerDirector.add_handler(handler)¶

handler باید نمونه‌ای از BaseHandler باشد. متدهای زیر جستجو می‌شوند و به زنجیره‌های ممکن اضافه می‌شوند (توجه داشته باشید که خطاهای HTTP حالت خاصی هستند). توجه داشته باشید که در ادامه، protocol باید با پروتکل واقعی برای مدیریت جایگزین شود، برای مثال http_response() هندلر پاسخ پروتکل HTTP خواهد بود. همچنین type باید با کد HTTP واقعی جایگزین شود، برای مثال http_error_404() خطاهای HTTP 404 را مدیریت می‌کند.

<protocol>_open() --- نشان می‌دهد که هندلر چگونگی باز کردن URLهای protocol را می‌داند.

برای اطلاعات بیشتر، BaseHandler.<protocol>_open() را ببینید.
http_error_<type>() --- نشان می‌دهد که هندلر می‌داند چگونه خطاهای HTTP با کد خطای HTTP type را مدیریت کند.

برای اطلاعات بیشتر، BaseHandler.http_error_<nnn>() را ببینید.
<protocol>_error() --- نشان می‌دهد که مدیر می‌داند چگونه خطاهای protocol (غیر http) را مدیریت کند.
<protocol>_request() --- نشان می‌دهد که هندلر می‌داند چگونه درخواست‌های protocol را پیش‌پردازش کند.

برای اطلاعات بیشتر BaseHandler.<protocol>_request() را ببینید.
<protocol>_response() --- نشان می‌دهد که هندلر می‌داند چگونه پاسخ‌های protocol را پس‌پردازش کند.

برای اطلاعات بیشتر، BaseHandler.<protocol>_response() را ببینید.

OpenerDirector.open(url, data=None[, timeout])¶: url داده‌شده را باز کنید (که می‌تواند یک شیء درخواست یا یک رشته باشد)، و به‌اختیار data داده‌شده را نیز ارسال کنید. آرگومان‌ها، مقادیر بازگشتی و استثناهای پرتاب‌شده همان موارد مربوط به urlopen() هستند (که به‌سادگی متد open() را روی OpenerDirector سراسری نصب‌شده‌ی کنونی فراخوانی می‌کند). پارامتر اختیاری timeout یک مهلت زمانی بر حسب ثانیه را برای عملیات‌های مسدودکننده مانند تلاش برای اتصال مشخص می‌کند (اگر مشخص نشده باشد، از تنظیم پیش‌فرض سراسری مهلت زمانی استفاده خواهد شد). قابلیت مهلت زمانی در عمل فقط برای اتصال‌های HTTP، HTTPS و FTP کار می‌کند.

OpenerDirector.error(proto, *args)¶

به یک خطا از پروتکل داده‌شده رسیدگی می‌کند. این کار، هندلرهای خطای ثبت‌شده برای پروتکل داده‌شده را با آرگومان‌های داده‌شده (که مختص پروتکل هستند) فراخوانی خواهد کرد. پروتکل HTTP یک حالت خاص است که از کد پاسخ HTTP برای تعیین هندلر خطای خاص استفاده می‌کند؛ به متدهای http_error_<type>() کلاس‌های هندلر مراجعه کنید.

مقادیر بازگشتی و استثناهای پرتاب‌شده همان موارد urlopen() هستند.

اشیای OpenerDirector نشانی‌های اینترنتی (URL) را در ۳ مرحله باز می‌کنند:

ترتیب فراخوانی این متدها در هر مرحله، با مرتب‌سازی نمونه‌های هندلر تعیین می‌شود.

هر هندلری که متدی با نامی شبیه <protocol>_request() دارد، آن متد برای پیش‌پردازش درخواست فراخوانی می‌شود.
هندلرهایی که متدی با نامی شبیه <protocol>_open() دارند، برای رسیدگی به درخواست فراخوانی می‌شوند. این مرحله زمانی پایان می‌یابد که یک مدیر یا مقداری غیر None برمی‌گرداند (یعنی یک پاسخ)، یا استثنایی را پرتاب می‌کند (معمولاً URLError). استثناها مجاز به انتشار هستند.

در واقع، الگوریتم بالا ابتدا برای متدهایی با نام default_open() اجرا می‌شود. اگر تمام چنین متدهایی None را برگردانند، الگوریتم برای متدهایی با نامی مانند <protocol>_open() تکرار می‌شود. اگر تمام چنین متدهایی None را برگردانند، الگوریتم برای متدهایی با نام unknown_open() تکرار می‌شود.

توجه داشته باشید که پیاده‌سازی این متدها ممکن است شامل فراخوانی متدهای open() و error() از نمونه والد OpenerDirector باشد.
هر هندلری که متدی با نامی مانند <protocol>_response() داشته باشد، آن متد برای پس‌پردازش پاسخ فراخوانی می‌شود.

اشیای BaseHandler¶

اشیای BaseHandler چند متد ارائه می‌دهند که مستقیماً مفید هستند، و متدهای دیگری نیز دارند که برای استفاده در کلاس‌های مشتق‌شده در نظر گرفته شده‌اند. این موارد برای استفاده‌ی مستقیم در نظر گرفته شده‌اند:

BaseHandler.add_parent(director)¶: یک مدیر را به‌عنوان والد اضافه کنید.

BaseHandler.close()¶: هرگونه والد را حذف کنید.

ویژگی و متدهای زیر فقط باید توسط کلاس‌های مشتق‌شده از BaseHandler استفاده شوند.

توجه

این قرارداد پذیرفته شده است که زیرکلاس‌هایی که متدهای <protocol>_request() یا <protocol>_response() را تعریف می‌کنند، *Processor نامیده می‌شوند؛ سایر موارد *Handler نامیده می‌شوند.

BaseHandler.parent¶: یک OpenerDirector معتبر، که می‌توان از آن برای باز کردن با پروتکلی متفاوت یا مدیریت خطاها استفاده کرد.

BaseHandler.default_open(req)¶

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را تعریف کنند که بخواهند همه‌ی URLها را بگیرند.

این متد، در صورت پیاده‌سازی، توسط والد OpenerDirector فراخوانی می‌شود. این متد باید یک شیء شبه‌پرونده را همان‌گونه که در مقدار بازگشتی متد open() از OpenerDirector آمده است، یا None برگرداند. باید URLError را پرتاب کند، مگر اینکه اتفاقی واقعاً استثنایی رخ دهد (برای مثال، نباید MemoryError به URLError نگاشت شود).

این متد پیش از هر متد open مختص پروتکل فراخوانی خواهد شد.

BaseHandler.<protocol>_open(req)

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را تعریف کنند که بخواهند URLهایی با پروتکل داده‌شده را مدیریت کنند.

این متد، در صورت تعریف‌شدن، توسط OpenerDirector والد فراخوانی خواهد شد. مقادیر بازگشتی باید همانند مقادیر بازگشتی برای default_open() باشند.

BaseHandler.unknown_open(req)¶

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را تعریف کنند که بخواهند همه‌ی URLهایی را که هیچ هندلر ثبت‌شده‌ی مشخصی برای باز کردن آن‌ها ندارند، بگیرند.

این متد، در صورت پیاده‌سازی، توسط parent OpenerDirector فراخوانی می‌شود. مقادیر بازگشتی باید همانند مقادیر بازگشتی default_open() باشند.

BaseHandler.http_error_default(req, fp, code, msg, hdrs)¶

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را بازنویسی کنند که قصد دارند یک هندلر کلی برای خطاهای HTTP فراهم کنند که در غیر این صورت رسیدگی نمی‌شوند. این متد به‌طور خودکار توسط OpenerDirector که خطا را دریافت می‌کند فراخوانی می‌شود و معمولاً نباید در شرایط دیگر فراخوانی شود.

OpenerDirector این متد را با پنج آرگومان جایگاهی فراخوانی می‌کند:

یک شیء Request،
یک شیء شبه‌پرونده حاوی بدنه‌ی خطای HTTP،
کد سه‌رقمی خطا، به‌صورت یک رشته،
توضیح کد که برای کاربر قابل مشاهده است، به‌صورت یک رشته، و
سرآیند‌های خطا، به‌عنوان یک شیء نگاشت.

مقادیر بازگشتی و استثناهای پرتاب‌شده باید همانند مقادیر و استثناهای urlopen() باشند.

BaseHandler.http_error_<nnn>(req, fp, code, msg, hdrs)

nnn باید یک کد خطای HTTP سه‌رقمی باشد. این متد نیز در BaseHandler تعریف نشده است، اما در صورت وجود، هنگامی که یک خطای HTTP با کد nnn رخ دهد، بر روی نمونه‌ای از یک زیرکلاس فراخوانی می‌شود.

زیرکلاس‌ها باید این متد را برای مدیریت خطاهای HTTP مشخص بازنویسی کنند.

آرگومان‌ها، مقادیر بازگشتی و استثناهای پرتاب‌شده باید مانند http_error_default() باشند.

BaseHandler.<protocol>_request(req)

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را تعریف کنند که بخواهند درخواست‌های پروتکل داده‌شده را پیش‌پردازش کنند.

این متد، در صورت تعریف، توسط والد OpenerDirector فراخوانی می‌شود. req یک شیء Request خواهد بود. مقدار بازگشتی باید یک شیء Request باشد.

BaseHandler.<protocol>_response(req, response)

این متد در BaseHandler تعریف نشده است، اما زیرکلاس‌ها باید در صورتی آن را تعریف کنند که بخواهند پاسخ‌های پروتکل داده‌شده را پس‌پردازش کنند.

این متد، در صورت تعریف، توسط والد OpenerDirector فراخوانی می‌شود. req یک شیء Request خواهد بود. response شیء‌ای خواهد بود که همان رابط مقدار بازگشتی urlopen() را پیاده‌سازی می‌کند. مقدار بازگشتی باید همان رابط مقدار بازگشتی urlopen() را پیاده‌سازی کند.

اشیای HTTPRedirectHandler¶

توجه

برخی تغییر مسیرهای HTTP به اقدام از سوی کد کلاینت این ماژول نیاز دارند. در این صورت، HTTPError پرتاب می‌شود. برای جزئیات معانی دقیق کدهای مختلف تغییر مسیر، RFC 2616 را ببینید.

استثنای HTTPError به‌عنوان یک ملاحظه امنیتی پرتاب می‌شود، اگر به HTTPRedirectHandler یک URL تغییرمسیر داده‌شده ارائه شود که یک URL از نوع HTTP، HTTPS یا FTP نباشد.

HTTPRedirectHandler.redirect_request(req, fp, code, msg, hdrs, newurl)¶: در پاسخ به یک تغییر مسیر، یک Request یا None برگردانید. این متد توسط پیاده‌سازی‌های پیش‌فرض متدهای http_error_30*() هنگامی که یک تغییر مسیر از سرور دریافت می‌شود، فراخوانی می‌شود. اگر باید تغییر مسیری انجام شود، یک Request جدید برگردانید تا http_error_30*() بتواند تغییر مسیر به newurl را انجام دهد. در غیر این صورت، اگر هیچ هندلر دیگری نباید برای مدیریت این URL تلاش کند، HTTPError را پرتاب کنید، یا اگر شما نمی‌توانید ولی هندلر دیگری ممکن است بتواند، None را برگردانید.

توجه

پیاده‌سازی پیش‌فرض این متد به‌طور دقیق از RFC 2616 پیروی نمی‌کند، که می‌گوید پاسخ‌های ۳۰۱ و ۳۰۲ به درخواست‌های POST نباید بدون تأیید کاربر به‌طور خودکار تغییرمسیر داده شوند. در واقعیت، مرورگرها تغییرمسیر خودکار این پاسخ‌ها را مجاز می‌دانند، POST را به GET تغییر می‌دهند، و پیاده‌سازی پیش‌فرض این رفتار را بازتولید می‌کند.

HTTPRedirectHandler.http_error_301(req, fp, code, msg, hdrs)¶: به نشانی اینترنتی Location: یا URI: هدایت مجدد می‌کند. این متد توسط OpenerDirector والد هنگام دریافت پاسخ «moved permanently» HTTP فراخوانی می‌شود.

HTTPRedirectHandler.http_error_302(req, fp, code, msg, hdrs)¶: مشابه http_error_301()، اما برای پاسخ 'found' فراخوانی می‌شود.

HTTPRedirectHandler.http_error_303(req, fp, code, msg, hdrs)¶: مشابه http_error_301()، اما برای پاسخ «see other» فراخوانی می‌شود.

HTTPRedirectHandler.http_error_307(req, fp, code, msg, hdrs)¶: همانند http_error_301() است، اما برای پاسخ «تغییر مسیر موقت» فراخوانی می‌شود. این متد اجازه نمی‌دهد روش درخواست از POST به GET تغییر کند.

HTTPRedirectHandler.http_error_308(req, fp, code, msg, hdrs)¶: همانند http_error_301()، اما برای پاسخ «تغییر مسیر دائم» فراخوانی می‌شود. این متد اجازه‌ی تغییر روش درخواست از POST به GET را نمی‌دهد.

اضافه شده در نسخه‌ی 3.11.

اشیاء HTTPCookieProcessor¶

نمونه‌های HTTPCookieProcessor یک ویژگی دارند:

HTTPCookieProcessor.cookiejar¶: http.cookiejar.CookieJar که کوکی‌ها در آن ذخیره می‌شوند.

اشیای ProxyHandler¶

ProxyHandler.<protocol>_open(request): ProxyHandler به ازای هر protocol که برای آن یک پراکسی در دیکشنری proxies داده‌شده به سازنده وجود دارد، یک متد <protocol>_open() خواهد داشت. این متد با فراخوانی request.set_proxy() درخواست‌ها را اصلاح می‌کند تا از طریق پراکسی عبور کنند، و مدیر بعدی در زنجیره را برای اجرای واقعی پروتکل فراخوانی می‌کند.

اشیاء HTTPPasswordMgr¶

این متدها بر روی اشیاء HTTPPasswordMgr و HTTPPasswordMgrWithDefaultRealm در دسترس هستند.

HTTPPasswordMgr.add_password(realm, uri, user, passwd)¶: uri can be either a single URI, or a sequence of URIs. realm, user and passwd must be strings. This causes (user, passwd) to be used as authentication tokens when authentication for realm and a super-URI of any of the given URIs is given. If a URI includes a scheme, its credentials only match authentication URIs with the same scheme or no scheme. A URI without a scheme matches authentication URIs with any scheme.

تغییر یافته در نسخه‌ی 3.14.7 (unreleased): Authentication credentials for URIs with a scheme are now scoped by that scheme.

HTTPPasswordMgr.find_user_password(realm, authuri)¶

نام کاربری/گذرواژه را برای قلمرو و URI داده‌شده، در صورت وجود، دریافت می‌کند. اگر هیچ نام کاربری/گذرواژه منطبقی وجود نداشته باشد، این متد (None, None) را برمی‌گرداند.

برای اشیای HTTPPasswordMgrWithDefaultRealm، اگر realm داده‌شده هیچ نام کاربری/گذرواژه‌ی منطبقی نداشته باشد، قلمرو None جستجو خواهد شد.

اشیاء HTTPPasswordMgrWithPriorAuth¶

این مدیر گذرواژه HTTPPasswordMgrWithDefaultRealm را گسترش می‌دهد تا از پیگیری URIهایی پشتیبانی کند که باید همیشه اعتبارنامه‌های احراز هویت برای آن‌ها ارسال شوند.

HTTPPasswordMgrWithPriorAuth.add_password(realm, uri, user, passwd, is_authenticated=False)¶: realm، uri، user و passwd همان‌گونه هستند که برای HTTPPasswordMgr.add_password() آمده‌اند. is_authenticated مقدار اولیه‌ی پرچم is_authenticated را برای URI داده‌شده یا فهرستی از URIها تنظیم می‌کند. اگر is_authenticated به‌صورت True تعیین شده باشد، realm نادیده گرفته می‌شود.

HTTPPasswordMgrWithPriorAuth.find_user_password(realm, authuri)¶: همانند اشیای HTTPPasswordMgrWithDefaultRealm

HTTPPasswordMgrWithPriorAuth.update_authenticated(self, uri, is_authenticated=False)¶: پرچم is_authenticated را برای uri داده‌شده یا فهرستی از URIها به‌روزرسانی کنید.

HTTPPasswordMgrWithPriorAuth.is_authenticated(self, authuri)¶: وضعیت فعلی پرچم is_authenticated را برای URI داده‌شده برمی‌گرداند.

اشیاء AbstractBasicAuthHandler¶

AbstractBasicAuthHandler.http_error_auth_reqed(authreq, host, req, headers)¶

با دریافت یک جفت کاربر/گذرواژه و تلاش دوباره برای درخواست، به یک درخواست احراز هویت رسیدگی کنید. authreq باید نام سرآیندی در درخواست باشد که اطلاعات مربوط به قلمرو در آن گنجانده شده است، host نشانی URL و مسیر برای احراز هویت را مشخص می‌کند، req باید شیء Request (ناموفق) باشد، و headers باید سرآیندهای خطا باشند.

headers must be a mapping-like object with case-insensitive lookup that implements the get_all() method, such as email.message.Message or wsgiref.headers.Headers.

host یا یک مرجع (authority) است (مثلاً "python.org") یا یک URL حاوی یک کامپوننت مرجع (authority) است (مثلاً "https://python.org/"). در هر دو حالت، مرجع (authority) نباید شامل یک کامپوننت اطلاعات کاربر (userinfo) باشد (بنابراین، "python.org" و "python.org:80" مجاز هستند، اما "joe:password@python.org" مجاز نیست).

اشیاء HTTPBasicAuthHandler¶

HTTPBasicAuthHandler.http_error_401(req, fp, code, msg, hdrs)¶: در صورت موجود بودن، درخواست را با اطلاعات احراز هویت دوباره ارسال کنید.

اشیای ProxyBasicAuthHandler¶

ProxyBasicAuthHandler.http_error_407(req, fp, code, msg, hdrs)¶: در صورت موجود بودن، درخواست را با اطلاعات احراز هویت دوباره ارسال کنید.

اشیاء AbstractDigestAuthHandler¶

AbstractDigestAuthHandler.http_error_auth_reqed(authreq, host, req, headers)¶

authreq باید نام سرآیندی باشد که اطلاعات مربوط به قلمرو در درخواست، در آن گنجانده شده است، host باید میزبانی باشد که در برابر آن احراز هویت می‌شود، req باید شیء ناموفق Request باشد، و headers باید سرآیندهای خطا باشند.

headers must be a mapping-like object with case-insensitive lookup, such as email.message.Message or wsgiref.headers.Headers.

اشیاء HTTPDigestAuthHandler¶

HTTPDigestAuthHandler.http_error_401(req, fp, code, msg, hdrs)¶: در صورت موجود بودن، درخواست را با اطلاعات احراز هویت دوباره ارسال کنید.

اشیای ProxyDigestAuthHandler¶

ProxyDigestAuthHandler.http_error_407(req, fp, code, msg, hdrs)¶: در صورت موجود بودن، درخواست را با اطلاعات احراز هویت دوباره ارسال کنید.

اشیای HTTPHandler¶

HTTPHandler.http_open(req)¶: یک درخواست HTTP ارسال کنید که بسته به req.data می‌تواند GET یا POST باشد.

اشیاء HTTPSHandler¶

HTTPSHandler.https_open(req)¶: یک درخواست HTTPS ارسال کنید، که بسته به req.data می‌تواند GET یا POST باشد.

اشیاء FileHandler¶

FileHandler.file_open(req)¶: اگر نام میزبانی وجود نداشته باشد یا نام میزبان 'localhost' باشد، پرونده را به‌صورت محلی باز کنید.

تغییر یافته در نسخه‌ی 3.2: این متد تنها برای نام‌های میزبان محلی کاربرد دارد. هنگامی که یک نام میزبان راه‌دور داده شود، یک URLError پرتاب می‌شود.

اشیای DataHandler¶

DataHandler.data_open(req)¶: یک URL داده (data URL) را بخوانید. این نوع URL شامل محتوایی است که در خود URL کدگذاری‌شده است. سینتکس URL داده در RFC 2397 مشخص شده است. این پیاده‌سازی فضاهای سفید را در URLهای داده‌ی کدگذاری‌شده با base64 نادیده می‌گیرد، بنابراین ممکن است URL در هر پرونده منبعی که از آن آمده است، شکسته شده باشد. اما حتی با وجود اینکه برخی مرورگرها به نبود پدینگ (padding) در انتهای یک URL داده‌ی کدگذاری‌شده با base64 اهمیتی نمی‌دهند، این پیاده‌سازی در آن حالت یک ValueError پرتاب می‌کند.

اشیای FTPHandler¶

FTPHandler.ftp_open(req)¶: پرونده FTP مشخص‌شده توسط req را باز کنید. ورود همیشه با نام کاربری خالی و گذرواژه خالی انجام می‌شود.

اشیای CacheFTPHandler¶

اشیای CacheFTPHandler، اشیای FTPHandler هستند که متدهای اضافی زیر را دارند:

CacheFTPHandler.setTimeout(t)¶: تنظیم مهلت اتصال‌ها روی t ثانیه.

CacheFTPHandler.setMaxConns(m)¶: حداکثر تعداد اتصالات نهانگاه‌شده را روی m تنظیم کنید.

اشیای UnknownHandler¶

UnknownHandler.unknown_open()¶: یک استثنا URLError پرتاب می‌کند.

اشیاء HTTPErrorProcessor¶

HTTPErrorProcessor.http_response(request, response)¶

پاسخ‌های خطای HTTP را پردازش می‌کند.

برای کدهای خطای ۲۰۰، شیء پاسخ بلافاصله بازگردانده می‌شود.

برای کدهای خطای غیر ۲۰۰، این به‌سادگی کار را از طریق OpenerDirector.error() به متدهای هندلر http_error_<type>() می‌سپارد. در نهایت، اگر هیچ هندلر دیگری خطا را مدیریت نکند، HTTPDefaultErrorHandler یک HTTPError پرتاب خواهد کرد.

HTTPErrorProcessor.https_response(request, response)¶

پردازش پاسخ‌های خطای HTTPS.

رفتار مشابه http_response() است.

مثال‌ها¶

علاوه بر مثال‌های زیر، مثال‌های بیشتری در راهنمای واکشی منابع اینترنتی با استفاده از بسته urllib ارائه شده‌اند.

این مثال صفحه اصلی python.org را دریافت می‌کند و نخستین ۳۰۰ بایت آن را نمایش می‌دهد:

>>> import urllib.request
>>> with urllib.request.urlopen('https://www.python.org/') as f:
...     # The response may be compressed (for example, 'gzip').
...     print(f.headers.get('Content-Encoding'))
...     data = f.read()
...     if f.headers.get('Content-Encoding') == 'gzip':
...         import gzip
...         data = gzip.decompress(data)
...     print(data[:300].decode('utf-8', errors='replace'))

توجه داشته باشید که urlopen یک شیء بایتی برمی‌گرداند. این به این دلیل است که urlopen هیچ راهی ندارد تا کدگذاری جریان بایتی را که از سرور HTTP دریافت می‌کند، به‌طور خودکار تعیین کند. به‌طور معمول، یک برنامه پس از تعیین یا حدس زدن کدگذاری مناسب، شیء بایتی برگردانده‌شده را به رشته کدگشایی می‌کند.

سند مشخصات HTML زیر، https://html.spec.whatwg.org/#charset، روش‌های مختلفی را فهرست می‌کند که یک سند HTML یا XML می‌توانسته اطلاعات کدگذاری خود را از طریق آن‌ها مشخص کرده باشد.

برای اطلاعات بیشتر، به سند W3C مراجعه کنید: https://www.w3.org/International/questions/qa-html-encoding-declarations.

از آن‌جا که وب‌سایت python.org، همان‌طور که در برچسب meta آن مشخص شده است، از کدگذاری utf-8 استفاده می‌کند، ما از همان کدگذاری برای کدگشایی شیء bytes استفاده خواهیم کرد:

>>> with urllib.request.urlopen('https://www.python.org/') as f:
...     # Check for compression and decode appropriately.
...     enc = f.headers.get('Content-Encoding')
...     data = f.read()
...     if enc == 'gzip':
...         import gzip
...         data = gzip.decompress(data)
...     print(data[:100].decode('utf-8', errors='replace'))
...

همچنین می‌توان بدون استفاده از روش مدیر زمینه به همان نتیجه دست یافت:

>>> import urllib.request
>>> f = urllib.request.urlopen('https://www.python.org/')
>>> try:
...     enc = f.headers.get('Content-Encoding')
...     data = f.read()
...     if enc == 'gzip':
...         import gzip
...         data = gzip.decompress(data)
...     print(data[:100].decode('utf-8', errors='replace'))
... finally:
...     f.close()

در مثال زیر، ما یک جریان داده را به stdin یک CGI ارسال می‌کنیم و داده‌ای را که به ما برمی‌گرداند می‌خوانیم. توجه داشته باشید که این مثال تنها زمانی کار می‌کند که پایتون نصب‌شده از SSL پشتیبانی کند.

>>> import urllib.request
>>> req = urllib.request.Request(url='https://localhost/cgi-bin/test.cgi',
...                       data=b'This data is passed to stdin of the CGI')
>>> with urllib.request.urlopen(req) as f:
...     print(f.read().decode('utf-8'))
...
Got Data: "This data is passed to stdin of the CGI"

کد CGI نمونه‌ی استفاده‌شده در مثال بالا به این صورت است:

#!/usr/bin/env python
import sys
data = sys.stdin.read()
print('Content-type: text/plain\n\nGot Data: "%s"' % data)

در اینجا نمونه‌ای از انجام یک درخواست PUT با استفاده از Request آمده است:

import urllib.request
DATA = b'some data'
req = urllib.request.Request(url='http://localhost:8080', data=DATA, method='PUT')
with urllib.request.urlopen(req) as f:
    pass
print(f.status)
print(f.reason)

استفاده از احراز هویت پایه HTTP:

import urllib.request
# Create an OpenerDirector with support for Basic HTTP Authentication...
auth_handler = urllib.request.HTTPBasicAuthHandler()
auth_handler.add_password(realm='PDQ Application',
                          uri='https://mahler:8092/site-updates.py',
                          user='klem',
                          passwd='kadidd!ehopper')
opener = urllib.request.build_opener(auth_handler)
# ...and install it globally so it can be used with urlopen.
urllib.request.install_opener(opener)
with urllib.request.urlopen('http://www.example.com/login.html') as f:
    print(f.read().decode('utf-8'))

build_opener() به‌طور پیش‌فرض بسیاری از هندلرها را فراهم می‌کند، از جمله یک ProxyHandler. به‌طور پیش‌فرض، ProxyHandler از متغیرهای محیطی با نام <scheme>_proxy استفاده می‌کند، که در آن <scheme> طرح‌واره URL مربوطه است. برای مثال، متغیر محیطی http_proxy خوانده می‌شود تا URL پراکسی HTTP به دست آید.

این مثال ProxyHandler پیش‌فرض را با نمونه‌ای جایگزین می‌کند که از نشانی‌های اینترنتی پراکسی ارائه‌شده به‌صورت برنامه‌ای استفاده می‌کند، و پشتیبانی از احراز هویت پراکسی را با ProxyBasicAuthHandler اضافه می‌کند.

proxy_handler = urllib.request.ProxyHandler({'http': 'http://www.example.com:3128/'})
proxy_auth_handler = urllib.request.ProxyBasicAuthHandler()
proxy_auth_handler.add_password('realm', 'host', 'username', 'password')

opener = urllib.request.build_opener(proxy_handler, proxy_auth_handler)
# This time, rather than install the OpenerDirector, we use it directly:
with opener.open('http://www.example.com/login.html') as f:
   print(f.read().decode('utf-8'))

افزودن سرآیندهای HTTP:

از آرگومان headers برای سازنده‌ی Request استفاده کنید، یا:

import urllib.request
req = urllib.request.Request('http://www.example.com/')
req.add_header('Referer', 'https://www.python.org/')
# Customize the default User-Agent header value:
req.add_header('User-Agent', 'urllib-example/0.1 (Contact: . . .)')
with urllib.request.urlopen(req) as f:
    print(f.read().decode('utf-8'))

OpenerDirector به‌طور خودکار یک سرآیند User-Agent را به هر Request اضافه می‌کند. برای تغییر این:

import urllib.request
opener = urllib.request.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0')]
with opener.open('http://www.example.com/') as f:
   print(f.read().decode('utf-8'))

همچنین، به یاد داشته باشید که هنگامی که Request به urlopen() (یا OpenerDirector.open()) ارسال می‌شود، چند سرآیند استاندارد (Content-Length، Content-Type و Host) افزوده می‌شوند.

در اینجا یک نشست نمونه آمده است که از متد GET برای بازیابی یک URL حاوی پارامترها استفاده می‌کند:

>>> import urllib.request
>>> import urllib.parse
>>> params = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
>>> url = "https://www.python.org/?%s" % params
>>> with urllib.request.urlopen(url) as f:
...     print(f.read().decode('utf-8'))
...

مثال زیر به‌جای آن از متد POST استفاده می‌کند. توجه داشته باشید که خروجی params از urlencode پیش از آنکه به‌عنوان data به urlopen ارسال شود، به بایت کدگذاری می‌شود:

>>> import urllib.request
>>> import urllib.parse
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
>>> data = data.encode('ascii')
>>> with urllib.request.urlopen("https://httpbin.org/post", data) as f:
...     print(f.read().decode('utf-8'))
...

مثال زیر از یک پراکسی HTTP به‌صراحت مشخص‌شده استفاده می‌کند و تنظیمات محیطی را نادیده می‌گیرد:

>>> import urllib.request
>>> proxies = {'http': 'http://proxy.example.com:8080/'}
>>> opener = urllib.request.build_opener(urllib.request.ProxyHandler(proxies))
>>> with opener.open("https://www.python.org") as f:
...     f.read().decode('utf-8')
...

مثال زیر به‌هیچ‌وجه از پراکسی استفاده نمی‌کند و تنظیمات محیطی را نادیده می‌گیرد:

>>> import urllib.request
>>> opener = urllib.request.build_opener(urllib.request.ProxyHandler({}))
>>> with opener.open("https://www.python.org/") as f:
...     f.read().decode('utf-8')
...

رابط قدیمی¶

توابع و کلاس‌های زیر از ماژول urllib در پایتون 2 منتقل شده‌اند (در مقابل urllib2). ممکن است روزی در آینده منسوخ شوند.

urllib.request.urlretrieve(url, filename=None, reporthook=None, data=None)¶

یک شیء شبکه‌ای را که با یک URL مشخص‌شده است، در یک پرونده محلی کپی می‌کند. اگر URL به یک پرونده محلی اشاره کند، شیء کپی نخواهد شد مگر اینکه filename داده شده باشد. یک تاپل (filename, headers) را برمی‌گرداند که filename نام پرونده محلی است که شیء در آن یافت می‌شود، و headers هر چیزی است که متد info() شیء برگردانده‌شده توسط urlopen() برگردانده است (برای یک شیء راه‌دور). استثناها همانند استثناهای urlopen() هستند.

آرگومان دوم، در صورت وجود، محل مقصدی را که پرونده در آن کپی می‌شود مشخص می‌کند (در صورت نبود، محل مقصد، یک پرونده موقت با نام تولیدشده خواهد بود). آرگومان سوم، در صورت وجود، یک شیء فراخوانی‌پذیر است که یک بار هنگام برقراری اتصال شبکه و یک بار پس از خواندن هر بلوک از آن پس فراخوانی می‌شود. به این شیء فراخوانی‌پذیر سه آرگومان داده می‌شود؛ تعداد بلوک‌های منتقل‌شده تاکنون، اندازه بلوک بر حسب بایت، و اندازه کل پرونده. آرگومان سوم ممکن است در سرورهای FTP قدیمی‌تر که در پاسخ به درخواست واکشی اندازه پرونده را برنمی‌گردانند، -1 باشد.

مثال زیر رایج‌ترین حالت استفاده را نشان می‌دهد:

>>> import urllib.request
>>> local_filename, headers = urllib.request.urlretrieve('https://python.org/')
>>> html = open(local_filename)
>>> html.close()

اگر url از شناسه‌ی طرح‌واره http: استفاده کند، می‌توان آرگومان اختیاری data را برای مشخص کردن یک درخواست POST ارائه داد (به‌طور معمول نوع درخواست GET است). آرگومان data باید یک شیء بایتی در قالب استاندارد application/x-www-form-urlencoded باشد؛ تابع urllib.parse.urlencode() را ببینید.

urlretrieve() هنگامی که تشخیص دهد مقدار داده‌ی در دسترس کمتر از مقدار مورد انتظار بوده است (که اندازه‌ی گزارش‌شده توسط یک سرآیند Content-Length است)، استثنای ContentTooShortError را پرتاب می‌کند. این ممکن است برای مثال زمانی رخ دهد که دانلود قطع شود.

Content-Length به‌عنوان یک کران پایین در نظر گرفته می‌شود: اگر داده بیشتری برای خواندن وجود داشته باشد، urlretrieve داده بیشتری می‌خواند، اما اگر داده کمتری در دسترس باشد، استثنا را پرتاب می‌کند.

در این حالت همچنان می‌توانید داده‌ی بارگیری‌شده را بازیابی کنید؛ این داده در ویژگی content نمونه‌ی استثنا ذخیره شده است.

اگر سرآیند Content-Length ارائه نشده باشد، urlretrieve نمی‌تواند اندازه‌ی داده‌ای را که بارگیری کرده است بررسی کند و فقط آن را برمی‌گرداند. در این حالت فقط باید فرض کنید که بارگیری موفق بوده است.

urllib.request.urlcleanup()¶: پرونده‌های موقتی را که ممکن است از فراخوانی‌های قبلی urlretrieve() باقی مانده باشند، پاک‌سازی می‌کند. همچنین بازکننده سراسری پیش‌فرض نصب‌شده توسط install_opener() را بازنشانی می‌کند.

محدودیت‌های `urllib.request`¶

در حال حاضر، فقط از پروتکل‌های زیر پشتیبانی می‌شود: HTTP (نسخه‌های 0.9 و 1.0)، FTP، پرونده‌های محلی و URLهای داده.

تغییر یافته در نسخه‌ی 3.4: پشتیبانی از نشانی‌های داده (data URLs) افزوده شد.
قابلیت نهان‌سازی urlretrieve() تا زمانی که کسی فرصت پیاده‌سازی پردازش صحیح سرآیندهای زمان انقضا را پیدا کند، غیرفعال شده است.
باید تابعی وجود داشته باشد که بتوان با آن پرس‌وجو کرد آیا یک URL خاص در نهانگاه وجود دارد یا خیر.
برای سازگاری با نسخه‌های قدیمی، اگر به نظر برسد که یک URL به یک پرونده محلی اشاره می‌کند اما آن پرونده باز نشود، URL دوباره با استفاده از پروتکل FTP تفسیر می‌شود. این موضوع گاهی می‌تواند پیام‌های خطای گیج‌کننده‌ای ایجاد کند.
توابع urlopen() و urlretrieve() می‌توانند در حین انتظار برای برقراری اتصال شبکه، تأخیرهای بسیار طولانی و غیرقابل پیش‌بینی ایجاد کنند. این بدان معناست که ساخت یک کلاینت وب تعاملی با استفاده از این توابع بدون استفاده از نخ‌ها دشوار است.
داده‌ای که توسط urlopen() یا urlretrieve() بازگشت داده می‌شود، همان داده‌ی خامی است که سرور بازمی‌گرداند. این داده ممکن است داده‌ی دودویی (مانند یک تصویر)، متن ساده یا (برای مثال) HTML باشد. پروتکل HTTP اطلاعات نوع را در سرآیند پاسخ ارائه می‌کند، که می‌توان با بررسی سرآیند Content-Type آن را مشاهده کرد. اگر داده‌ی بازگشتی HTML باشد، می‌توانید برای تجزیه‌ی آن از ماژول html.parser استفاده کنید.
کدی که پروتکل FTP را مدیریت می‌کند، نمی‌تواند میان یک پرونده و یک پوشه تمایز قائل شود. این موضوع می‌تواند هنگام تلاش برای خواندن یک URL که به پرونده‌ای غیرقابل دسترسی اشاره می‌کند، به رفتار غیرمنتظره‌ای منجر شود. اگر URL با / پایان یابد، فرض می‌شود که به یک پوشه اشاره دارد و بر همین اساس مدیریت خواهد شد. اما اگر تلاش برای خواندن یک پرونده به خطای ۵۵۰ منجر شود (به این معنا که URL پیدا نمی‌شود یا قابل دسترسی نیست، اغلب به دلایل مربوط به مجوزها)، مسیر به‌عنوان یک پوشه در نظر گرفته می‌شود تا حالتی که در آن یک پوشه با URL مشخص شده اما / پایانی آن حذف شده است مدیریت شود. این می‌تواند هنگامی که سعی می‌کنید پرونده‌ای را واکشی کنید که مجوزهای خواندن آن را غیرقابل دسترسی کرده‌اند، نتایج گمراه‌کننده‌ای ایجاد کند؛ کد FTP تلاش می‌کند آن را بخواند، با خطای ۵۵۰ شکست می‌خورد و سپس برای پرونده غیرقابل خواندن، فهرست پوشه تهیه می‌کند. اگر به کنترل دقیق‌تری نیاز دارید، استفاده از ماژول ftplib را در نظر بگیرید.

`urllib.response` --- کلاس‌های پاسخ مورد استفاده urllib¶

ماژول urllib.response توابع و کلاس‌هایی را تعریف می‌کند که یک رابط حداقلی شبه‌پرونده را تعریف می‌کنند، شامل read() و readline(). توابع تعریف‌شده در این ماژول به‌صورت داخلی توسط ماژول urllib.request استفاده می‌شوند. شیء پاسخ معمول یک نمونه از urllib.response.addinfourl است:

class urllib.response.addinfourl¶

url¶: URL منبع بازیابی‌شده، که معمولاً برای تشخیص اینکه آیا یک تغییر مسیر دنبال شده است استفاده می‌شود.

headers¶: سرآیندهای پاسخ را در قالب یک نمونه از EmailMessage بازمی‌گرداند.

status¶: اضافه شده در نسخه‌ی 3.9.

کد وضعیت برگردانده‌شده از سرور.

geturl()¶: منسوخ شده از نسخه‌ی 3.9: به نفع url منسوخ شده است.

info()¶: منسوخ شده از نسخه‌ی 3.9: منسوخ‌شده به نفع headers.

code¶: منسوخ شده از نسخه‌ی 3.9: منسوخ شده است؛ به جای آن از status استفاده کنید.

getcode()¶: منسوخ شده از نسخه‌ی 3.9: منسوخ شده است؛ به جای آن از status استفاده کنید.

`urllib.request` --- کتابخانه‌ی گسترش‌پذیر برای باز کردن URLها¶

اشیای درخواست¶

اشیای OpenerDirector¶

اشیای BaseHandler¶

اشیای HTTPRedirectHandler¶

اشیاء HTTPCookieProcessor¶

اشیای ProxyHandler¶

اشیاء HTTPPasswordMgr¶

اشیاء HTTPPasswordMgrWithPriorAuth¶

اشیاء AbstractBasicAuthHandler¶

اشیاء HTTPBasicAuthHandler¶

اشیای ProxyBasicAuthHandler¶

اشیاء AbstractDigestAuthHandler¶

اشیاء HTTPDigestAuthHandler¶

اشیای ProxyDigestAuthHandler¶

اشیای HTTPHandler¶

اشیاء HTTPSHandler¶

اشیاء FileHandler¶

اشیای DataHandler¶

اشیای FTPHandler¶

اشیای CacheFTPHandler¶

اشیای UnknownHandler¶

اشیاء HTTPErrorProcessor¶

مثال‌ها¶

رابط قدیمی¶

محدودیت‌های `urllib.request`¶

`urllib.response` --- کلاس‌های پاسخ مورد استفاده urllib¶

فهرست مطالب

موضوع قبلی

موضوع بعدی

این صفحه

urllib.request --- کتابخانه‌ی گسترش‌پذیر برای باز کردن URLها¶

اشیای درخواست¶

اشیای OpenerDirector¶

اشیای BaseHandler¶

اشیای HTTPRedirectHandler¶

اشیاء HTTPCookieProcessor¶

اشیای ProxyHandler¶

اشیاء HTTPPasswordMgr¶

اشیاء HTTPPasswordMgrWithPriorAuth¶

اشیاء AbstractBasicAuthHandler¶

اشیاء HTTPBasicAuthHandler¶

اشیای ProxyBasicAuthHandler¶

اشیاء AbstractDigestAuthHandler¶

اشیاء HTTPDigestAuthHandler¶

اشیای ProxyDigestAuthHandler¶

اشیای HTTPHandler¶

اشیاء HTTPSHandler¶

اشیاء FileHandler¶

اشیای DataHandler¶

اشیای FTPHandler¶

اشیای CacheFTPHandler¶

اشیای UnknownHandler¶

اشیاء HTTPErrorProcessor¶

مثال‌ها¶

رابط قدیمی¶

محدودیت‌های urllib.request¶

urllib.response --- کلاس‌های پاسخ مورد استفاده urllib¶

`urllib.request` --- کتابخانه‌ی گسترش‌پذیر برای باز کردن URLها¶

محدودیت‌های `urllib.request`¶

`urllib.response` --- کلاس‌های پاسخ مورد استفاده urllib¶