پروتکل انتقال ابرمتن: تفاوت میان نسخه‌ها

از ویکی‌پدیا، دانشنامهٔ آزاد
نمایش تاریخچه به صورت تعاملی
→ تفاوت قدیمی‌ترتفاوت جدیدتر ←
محتوای حذف‌شده محتوای افزوده‌شده
دیداریویکی‌متن
Rezabot (بحث | مشارکت‌ها)
ربات‌ها، مدیران رباتیک
۴٬۴۱۱٬۲۶۸ ویرایش‌ها
جز v1.39b - اصلاح شده توسط ابزار تمیرکاری> (دارای نویسه‌های نادرست که باید جایگزین شوند)
برچسب: WPCleaner
جز اصلاح نویسه نادرست با استفاده از AWB
خط ۱: خط ۱:
{{پشته پروتکل اینترنت}}
{{پشته پروتکل اینترنت}}
'''منشور انتقال ابرمتن''' {{به انگلیسی|Hypertext Transfer Protocol}} {{مخفف انگلیسی|HTTP}} یک [[قرارداد (رایانه)|پروتکل]] [[لایه کاربرد|لایهٔ کاربرد (Application Layer)]] برای [[رایانش توزیع‌شده|سیستم‎های توزیع شده]] می‎باشد. این پروتکل عمومی علاوه بر استفاده اصلی آن در [[ابرمتن|ابرمتن‎ها]] در بسیاری از زمینه‎های دیگر کامپیوتری مانند [[سامانهٔ نام دامنه]] (DNS) قابل استفاده است. از نسخه اولیه، این پروتکل در [[وب جهانی]] استفاده می‎شد و آخرین به‎روز رسانی آن در ماه جون ۱۹۹۹ تحت عنوان «HTTP/1.1» صورت گرفت. <ref name="rfc_2616">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc2616|عنوان= RFC 2616 - HTTP/1.1| ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ = جون ۱۹۹۹|تاریخ بازبینی= }}</ref>
'''منشور انتقال ابرمتن''' {{به انگلیسی|Hypertext Transfer Protocol}} {{مخفف انگلیسی|HTTP}} یک [[قرارداد (رایانه)|پروتکل]] [[لایه کاربرد|لایهٔ کاربرد (Application Layer)]] برای [[رایانش توزیع‌شده|سیستم‌های توزیع شده]] می‌باشد. این پروتکل عمومی علاوه بر استفاده اصلی آن در [[ابرمتن|ابرمتن‌ها]] در بسیاری از زمینه‌های دیگر کامپیوتری مانند [[سامانهٔ نام دامنه]] (DNS) قابل استفاده است. از نسخه اولیه، این پروتکل در [[وب جهانی]] استفاده می‌شد و آخرین به‌روز رسانی آن در ماه جون ۱۹۹۹ تحت عنوان «HTTP/1.1» صورت گرفت.<ref name="rfc_2616">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc2616|عنوان= RFC 2616 - HTTP/1.1| ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ = جون ۱۹۹۹|تاریخ بازبینی= }}</ref>


گسترش این پروتکل بر عهدهٔ [[نیروی ضربت مهندسی اینترنت]] (IETF) و [[کنسرسیوم وب جهان‌شمول]] (W3C) ) است. این امر در [[گروه کاری پروتکل انتقال ابرمتن]] (HTTP Working Group) صورت می‎گیرد.
گسترش این پروتکل بر عهدهٔ [[نیروی ضربت مهندسی اینترنت]] (IETF) و [[کنسرسیوم وب جهان‌شمول]] (W3C) ) است. این امر در [[گروه کاری پروتکل انتقال ابرمتن]] (HTTP Working Group) صورت می‌گیرد.


== تاریخچه ==
== تاریخچه ==
[[پرونده:Tim Berners-Lee CP 2.jpg|بندانگشتی|چپ|150px|[[تیم برنرز لی]]، به وجود آورندهٔ [[وب جهانی]]]]
[[پرونده:Tim Berners-Lee CP 2.jpg|بندانگشتی|چپ|150px|[[تیم برنرز لی]]، به وجود آورندهٔ [[وب جهانی]]]]
[[تیم برنرز لی]]، طراح و پیشنهاد دهنده [[وب جهانی]] که اکنون تحت عنوان WWW شناخته می‎شود، برای اولین بار پروتکل انتقال ابرمتن را به همراه ساختار اولیهٔ [[اچ‌تی‌ام‌ال|زبان نشانه گذاری ابرمتن (HTML)]] در یک [[وب سرور]] ساده و یک [[مرورگر]] مبتنی بر متن ارائه داد. در این نسخهٔ اولیه تنها روش درخواست (Request Method) موجود GET و تمامی پاسخ ها به زبان HTML بودند.<ref name="first_http">{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Protocols/HTTP/AsImplemented.html |عنوان= نسخهٔ اولیهٔ HTTP| ناشر = [[کنسرسیوم وب جهان‌شمول|کنسرسیوم وب]]|تاریخ = |تاریخ بازبینی= }}</ref>
[[تیم برنرز لی]]، طراح و پیشنهاد دهنده [[وب جهانی]] که اکنون تحت عنوان WWW شناخته می‌شود، برای اولین بار پروتکل انتقال ابرمتن را به همراه ساختار اولیهٔ [[اچ‌تی‌ام‌ال|زبان نشانه گذاری ابرمتن (HTML)]] در یک [[وب سرور]] ساده و یک [[مرورگر]] مبتنی بر متن ارائه داد. در این نسخهٔ اولیه تنها روش درخواست (Request Method) موجود GET و تمامی پاسخ ها به زبان HTML بودند.<ref name="first_http">{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Protocols/HTTP/AsImplemented.html |عنوان= نسخهٔ اولیهٔ HTTP| ناشر = [[کنسرسیوم وب جهان‌شمول|کنسرسیوم وب]]|تاریخ = |تاریخ بازبینی= }}</ref>


اولین نسخهٔ مستند پروتکل انتقال ابرمتن نسخهٔ ۰٫۹ آن بود که در سال ۱۹۹۱ منتشر شد. <ref name="first_http" /> [[دیو راگت]]، که در سال ۱۹۹۵ [[گروه کاری پروتکل انتقال ابرمتن]] (HTTP Working Group) را رهبری می‎کرد، خواستار گسترش این پروتکل شد و نهایتاً نسخه ۱٫۰ تحت عنوان «HTTP/1.0» در سال ۱۹۹۶ به صورت رسمی معرفی شد.<ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/People/Raggett/profile.html|عنوان= زندگینامهٔ دیو راگر | ناشر = |تاریخ = |تاریخ بازبینی= }}</ref><ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Arena/webworld/httpwgplans.html|عنوان= برنامه‎ریزی گروه کاری HTTP در سال ۱۹۹۵ | ناشر = |تاریخ = |تاریخ بازبینی= }}</ref>
اولین نسخهٔ مستند پروتکل انتقال ابرمتن نسخهٔ ۰٫۹ آن بود که در سال ۱۹۹۱ منتشر شد.<ref name="first_http" /> [[دیو راگت]]، که در سال ۱۹۹۵ [[گروه کاری پروتکل انتقال ابرمتن]] (HTTP Working Group) را رهبری می‌کرد، خواستار گسترش این پروتکل شد و نهایتاً نسخه ۱٫۰ تحت عنوان «HTTP/1.0» در سال ۱۹۹۶ به صورت رسمی معرفی شد.<ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/People/Raggett/profile.html|عنوان= زندگینامهٔ دیو راگر | ناشر = |تاریخ = |تاریخ بازبینی= }}</ref><ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Arena/webworld/httpwgplans.html|عنوان= برنامه‌ریزی گروه کاری HTTP در سال ۱۹۹۵ | ناشر = |تاریخ = |تاریخ بازبینی= }}</ref>


گروه کاری این پروتکل در ژانویه سال ۱۹۹۷ اولین استاندارد نسخهٔ ۱٫۱ را که در همان زمان توسط بسیاری از [[مرورگر|مرورگرها]] پشتیبانی می‎شد<ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html |عنوان= توضیحات پیشرفت پروتکل انتقال ابرمتن نسل جدید | ناشر = [[کنسرسیوم وب جهان‌شمول|کنسرسیوم وب]] |تاریخ = |تاریخ بازبینی= }}</ref>، به صورت رسمی منتشر کرد.<ref>{{یادکرد وب |نویسنده = گروه کاری پروتکل انتقال ابرمتن |نشانی= http://tools.ietf.org/html/rfc2068|عنوان= RFC 2068 | ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ = ژانویه ۱۹۹۷|تاریخ بازبینی= }}</ref> آخرین به‎روز رسانی نسخهٔ ۱٫۱ در جون سال ۱۹۹۹ در درخواست شماره ۲۶۱۶ (RFC 2616) انجام شد.<ref name="rfc_2616" />
گروه کاری این پروتکل در ژانویه سال ۱۹۹۷ اولین استاندارد نسخهٔ ۱٫۱ را که در همان زمان توسط بسیاری از [[مرورگر|مرورگرها]] پشتیبانی می‌شد<ref>{{یادکرد وب |نویسنده = |نشانی= http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html |عنوان= توضیحات پیشرفت پروتکل انتقال ابرمتن نسل جدید | ناشر = [[کنسرسیوم وب جهان‌شمول|کنسرسیوم وب]] |تاریخ = |تاریخ بازبینی= }}</ref>، به صورت رسمی منتشر کرد.<ref>{{یادکرد وب |نویسنده = گروه کاری پروتکل انتقال ابرمتن |نشانی= http://tools.ietf.org/html/rfc2068|عنوان= RFC 2068 | ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ = ژانویه ۱۹۹۷|تاریخ بازبینی= }}</ref> آخرین به‌روز رسانی نسخهٔ ۱٫۱ در جون سال ۱۹۹۹ در درخواست شماره ۲۶۱۶ (RFC 2616) انجام شد.<ref name="rfc_2616" />


== ساختار کلی ==
== ساختار کلی ==
پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل [[مدل کارخواه-کارساز|کلاینت–سرور]] می‎باشد. برای مثال یک [[مرورگر وب]] می تواند یک ''کلاینت'' و نرم‎افزار موجود بر روی سرویس‎دهندهٔ وبسایت، یک ''سرور'' باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفت‎وگو را آغاز می‎کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‎گذارد و یا عملیات خاصی را انجام می‎دهد. نتیجهٔ این عملِ سرور در بستهٔ پاسخ HTTP برای کلاینت ارسال می‎شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‎باشد.
پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل [[مدل کارخواه-کارساز|کلاینت–سرور]] می‌باشد. برای مثال یک [[مرورگر وب]] می تواند یک ''کلاینت'' و نرم‌افزار موجود بر روی سرویس‌دهندهٔ وبسایت، یک ''سرور'' باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفت‌وگو را آغاز می‌کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‌گذارد و یا عملیات خاصی را انجام می‌دهد. نتیجهٔ این عملِ سرور در بستهٔ پاسخ HTTP برای کلاینت ارسال می‌شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‌باشد.


مرورگر وب یک نمونه از [[عامل کاربر]] {{به انگلیسی|User Agent}} است. از دیگر عوامل کاربر می‎توان به [[خزنده‌ی وب|خزندهٔ وب]]، نرم‎افزار های [[تلفن همراه|تلفن‎های همراه]] و نرم‎افزار های دیگری که به وب متصل شده و از اطلاعات آن استفاده و یا صفحه‎ای را نمایش می‎دهند، اشاره کرد.
مرورگر وب یک نمونه از [[عامل کاربر]] {{به انگلیسی|User Agent}} است. از دیگر عوامل کاربر می‌توان به [[خزنده‌ی وب|خزندهٔ وب]]، نرم‌افزار های [[تلفن همراه|تلفن‌های همراه]] و نرم‌افزار های دیگری که به وب متصل شده و از اطلاعات آن استفاده و یا صفحه‌ای را نمایش می‌دهند، اشاره کرد.


پروتکل انتقال ابرمتن یک پروتکل [[لایهٔ کاربرد]] است که در [[مجموعه پروتکل اینترنت]] طراحی شده و مورد استفاده قرار می‌گیرد. این پروتکل با فرض اینکه [[لایه حمل|لایهٔ حمل (Transport Layer)]] زیرین آن قابل اعتماد است طراحی شده و معمولاً از [[قرارداد هدایت انتقال|پروتکل هدایت انتقال (TCP)]] به عنوان لایهٔ زیرین استفاده می‎کند. با این حال از این پروتکل بر روی لایه‎های غیرقابل اطمینان نیز استفاده می‎شود. مثلا در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی [[قرارداد داده‌نگار کاربر|پروتکل داده‎نگار کاربر]] (یک پروتکل غیر امن) مورد استفاده قرار می‎گیرد.
پروتکل انتقال ابرمتن یک پروتکل [[لایهٔ کاربرد]] است که در [[مجموعه پروتکل اینترنت]] طراحی شده و مورد استفاده قرار می‌گیرد. این پروتکل با فرض اینکه [[لایه حمل|لایهٔ حمل (Transport Layer)]] زیرین آن قابل اعتماد است طراحی شده و معمولاً از [[قرارداد هدایت انتقال|پروتکل هدایت انتقال (TCP)]] به عنوان لایهٔ زیرین استفاده می‌کند. با این حال از این پروتکل بر روی لایه‌های غیرقابل اطمینان نیز استفاده می‌شود. مثلا در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی [[قرارداد داده‌نگار کاربر|پروتکل داده‌نگار کاربر]] (یک پروتکل غیر امن) مورد استفاده قرار می‌گیرد.


منابع HTTP همگی با یک [[یوآرآی|شناسانهٔ یکنواخت منبع (URI)]] یا به طور مشخص‎تر با یک [[نشانی وب|نشانی وب (URL)]] آدرس‎دهی و مشخص می‎شوند. تمامی این آدرس‎ها با نشانهٔ http یا https آغاز می‎گردد. از این آدرس‎ها در [[زبان نشانه‌گذاری ابرمتنی|زبان نشانه‌گذاری ابرمتن]] به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‎گردد و از آن تحت عنوان [[ابرپیوند|پیوند یا لینک]] یاد می‎شود.
منابع HTTP همگی با یک [[یوآرآی|شناسانهٔ یکنواخت منبع (URI)]] یا به طور مشخص‌تر با یک [[نشانی وب|نشانی وب (URL)]] آدرس‌دهی و مشخص می‌شوند. تمامی این آدرس‌ها با نشانهٔ http یا https آغاز می‌گردد. از این آدرس‌ها در [[زبان نشانه‌گذاری ابرمتنی|زبان نشانه‌گذاری ابرمتن]] به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‌گردد و از آن تحت عنوان [[ابرپیوند|پیوند یا لینک]] یاد می‌شود.


نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال {{به انگلیسی|Connection}} برای چندین درخواست را دارد. مثلا می‎تواند عکس‎ها، فایل‎های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند. لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته است.
نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال {{به انگلیسی|Connection}} برای چندین درخواست را دارد. مثلا می‌تواند عکس‌ها، فایل‌های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند. لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته است.


== جلسه ==
== جلسه ==
در پروتکل انتقال ابرمتن به دنباله‎ای از درخواست‎ها و پاسخ‎ها جلسه {{به انگلیسی|Session}} گفته می‎شود. کلاینت با ایجاد یک اتصال [[قرارداد هدایت انتقال|هدایت انتقال (TCP)]] بر روی یک درگاهِ از پیش تعیین شده بر روی سرور ( معمولا درگاه شماره ۸۰؛ [[فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی]] )، جلسه را آغاز می‎کند. سرور وب همواره بر روی درگاه در انتظار درخواست‎های کلاینت‎ها می‎باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت {{به انگلیسی|Status Line}} و بدنه، پاسخ کلاینت را به او بازمی‎گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‎شود.<ref name="rfc_2616" />
در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه {{به انگلیسی|Session}} گفته می‌شود. کلاینت با ایجاد یک اتصال [[قرارداد هدایت انتقال|هدایت انتقال (TCP)]] بر روی یک درگاهِ از پیش تعیین شده بر روی سرور ( معمولا درگاه شماره ۸۰؛ [[فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی]] )، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت {{به انگلیسی|Status Line}} و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.<ref name="rfc_2616" />


یک نمونه از ''خط وضعیت'' در پاسخ به یک درخواست مجاز:
یک نمونه از ''خط وضعیت'' در پاسخ به یک درخواست مجاز:
خط ۳۱: خط ۳۱:
{{پایان چپ‌چین}}
{{پایان چپ‌چین}}


=== روش‎های درخواست ===
=== روش‌های درخواست ===
پروتکل انتقال ابرمتن روش‎هایی را برای درخواست تعریف کرده است {{به انگلیسی|Request Method}}که هر کدام از آن‎ها باعث انجام عمل خاص در سمت سرور می‎شوند. نسخهٔ ۱٫۰ روش‎های درخواست GET، POST و HEAD را دارا بود.<ref name="rfc_1945">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc1945|عنوان= RFC 1945 - HTTP/1.0| ناشر = [[نیروی ضربت مهندسی اینترنت]]}}</ref><sup>[بخش ۸]</sup>
پروتکل انتقال ابرمتن روش‌هایی را برای درخواست تعریف کرده است {{به انگلیسی|Request Method}}که هر کدام از آن‌ها باعث انجام عمل خاص در سمت سرور می‌شوند. نسخهٔ ۱٫۰ روش‌های درخواست GET، POST و HEAD را دارا بود.<ref name="rfc_1945">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc1945|عنوان= RFC 1945 - HTTP/1.0| ناشر = [[نیروی ضربت مهندسی اینترنت]]}}</ref><sup>[بخش ۸]</sup>
در نسخهٔ ۱٫۱ پنج روش جدید افزوده شد<ref name="rfc_2616" /><sup>[بخش ۹]</sup>: OPTIONS، PUT، DELETE، TRACE و CONNECT. از آنجایی که عملکرد این روش‎ها به طور کامل تعریف و شرح داده شده است، لذا تمامی [[مرورگر|مرورگر ها]] و سرور ها به راحتی می‎توانند این روش‎ها را پیاده‎سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. در تعداد روش‎ها هیچ محدودیتی وجود ندارد. این نکته باعث می‎شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‎ها فعلی آن آسیبی نرساند و آن‎ها را تغییر ندهد. برای مثال در حال حاضر [[پروتکل WebDAV]] هفت روش جدید درخواست را تعریف کرده است. <ref name="rfc_5789">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc5789|عنوان= RFC 5789 | ناشر = [[نیروی ضربت مهندسی اینترنت]]| تاریخ= مارچ ۲۰۱۰}}</ref>
در نسخهٔ ۱٫۱ پنج روش جدید افزوده شد<ref name="rfc_2616" /><sup>[بخش ۹]</sup>: OPTIONS، PUT، DELETE، TRACE و CONNECT. از آنجایی که عملکرد این روش‌ها به طور کامل تعریف و شرح داده شده است، لذا تمامی [[مرورگر|مرورگر ها]] و سرور ها به راحتی می‌توانند این روش‌ها را پیاده‌سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. در تعداد روش‌ها هیچ محدودیتی وجود ندارد. این نکته باعث می‌شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‌ها فعلی آن آسیبی نرساند و آن‌ها را تغییر ندهد. برای مثال در حال حاضر [[پروتکل WebDAV]] هفت روش جدید درخواست را تعریف کرده است.<ref name="rfc_5789">{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc5789|عنوان= RFC 5789 | ناشر = [[نیروی ضربت مهندسی اینترنت]]| تاریخ= مارچ ۲۰۱۰}}</ref>


; '''GET''': درخواست نمایش منبعِ درخواست‎داده‎شده را می‎دهد. (این منبع معمولا یک [[پرونده (رایانه)|فایل یا پرونده]] می‎باشد.) این روش فقط اطلاعات را از سرور دریافت می‎کند و نباید هیچ تاثیری بر روی منابع سرور بگذارد.
; '''GET''': درخواست نمایش منبعِ درخواست‌داده‌شده را می‌دهد. (این منبع معمولا یک [[پرونده (رایانه)|فایل یا پرونده]] می‌باشد.) این روش فقط اطلاعات را از سرور دریافت می‌کند و نباید هیچ تاثیری بر روی منابع سرور بگذارد.
; '''HEAD''': این روش دقیقا مانند روش GET عمل می‎کند ''با این تفاوت که بدنه پاسخ را نمی‎خواهد''. از این روش برای به‎دست‎آوردن [[فراداده|فراداده‎های]] موجود در سرآیند {{به انگلیسی|Header}} استفاده می‎شود. یکی از استفاده‎های رایج این نوع درخواست، بررسی تغییر یافتن یک منبع است.
; '''HEAD''': این روش دقیقا مانند روش GET عمل می‌کند ''با این تفاوت که بدنه پاسخ را نمی‌خواهد''. از این روش برای به‌دست‌آوردن [[فراداده|فراداده‌های]] موجود در سرآیند {{به انگلیسی|Header}} استفاده می‌شود. یکی از استفاده‌های رایج این نوع درخواست، بررسی تغییر یافتن یک منبع است.
; '''POST''': در این روش به همراه بستهٔ درخواست اطلاعاتی نیز فرستاده می‎شود. سرور با توجه به [[نشانی وب|نشانی وب (URL)]] درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‎گرداند. این اطلاعات ارسالی می‎تواند نامِ‎کاربری و کلمهٔ‎عبور، یک نظر بر روی یک مطلب و یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده است، باشد.<ref name="rfc_2616"/><sup>[بخش ۹٫۵]</sup>
; '''POST''': در این روش به همراه بستهٔ درخواست اطلاعاتی نیز فرستاده می‌شود. سرور با توجه به [[نشانی وب|نشانی وب (URL)]] درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‌گرداند. این اطلاعات ارسالی می‌تواند نامِ‌کاربری و کلمهٔ‌عبور، یک نظر بر روی یک مطلب و یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده است، باشد.<ref name="rfc_2616"/><sup>[بخش ۹٫۵]</sup>
; '''PUT''': در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‎شود که این منبع را در [[یوآرآی|آدرس]] موجود در بسته [[بارگذاری]] کند. اگر در محلِ درخواست شده قبلا منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد.
; '''PUT''': در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‌شود که این منبع را در [[یوآرآی|آدرس]] موجود در بسته [[بارگذاری]] کند. اگر در محلِ درخواست شده قبلا منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد.
; '''DELETE''': از سرور درخواست می‎کند که [[یوآرآی|آدرس]] فرستاده شده را حذف نماید.
; '''DELETE''': از سرور درخواست می‌کند که [[یوآرآی|آدرس]] فرستاده شده را حذف نماید.
; '''TRACE''': در این روش سرور اطلاعات ارسال شده را ''عیناً'' به کلاینت باز می‎گرداند. (برای بررسی تغییراتی که واسط‎های شبکه بر روی بسته می‎گذارند، از این روش استفاده می‎شود.)
; '''TRACE''': در این روش سرور اطلاعات ارسال شده را ''عیناً'' به کلاینت باز می‌گرداند. (برای بررسی تغییراتی که واسط‌های شبکه بر روی بسته می‌گذارند، از این روش استفاده می‌شود.)
; '''OPTIONS''': از سرور تقاضا می‎کند تا روش‎های درخواستِ {{به انگلیسی|Request Method}} موجود برای [[نشانی وب|نشانی]] فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‎های درخواست قابل اجرا بر روی سرور می‎توان از نشانی '*' استفاده کرد.
; '''OPTIONS''': از سرور تقاضا می‌کند تا روش‌های درخواستِ {{به انگلیسی|Request Method}} موجود برای [[نشانی وب|نشانی]] فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‌های درخواست قابل اجرا بر روی سرور می‌توان از نشانی '*' استفاده کرد.
; '''CONNECT''': بستهٔ پروتکل ابرمتن را به یک تونل TCP/IP تبدیل می‎کند. این عمل معمولاً برای برقراری ارتباط امن ([[پروتکل امن انتقال ابرمتن|HTTPS]]) بر روی یک [[پراکسی سرور]] ناامن استفاده می‎شود.<ref>{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc2817|عنوان= RFC 2817 - Upgrading to TLS Within HTTP/1.1"| ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ= سال ۲۰۰۰}}</ref>
; '''CONNECT''': بستهٔ پروتکل ابرمتن را به یک تونل TCP/IP تبدیل می‌کند. این عمل معمولاً برای برقراری ارتباط امن ([[پروتکل امن انتقال ابرمتن|HTTPS]]) بر روی یک [[پراکسی سرور]] ناامن استفاده می‌شود.<ref>{{یادکرد وب |نویسنده = |نشانی= http://tools.ietf.org/html/rfc2817|عنوان= RFC 2817 - Upgrading to TLS Within HTTP/1.1"| ناشر = [[نیروی ضربت مهندسی اینترنت]]|تاریخ= سال ۲۰۰۰}}</ref>
; '''PATCH''': این روش که در سال ۲۰۱۰ به پروتکل افزوده شد، برای ایجاد تغییرات جزیی بر روی منابع استفاده می‎شود.<ref name="rfc_5789" />
; '''PATCH''': این روش که در سال ۲۰۱۰ به پروتکل افزوده شد، برای ایجاد تغییرات جزیی بر روی منابع استفاده می‌شود.<ref name="rfc_5789" />


سرورهای وب موظف هستند حداقل روش‎های GET و HEAD را پیاده‎سازی نمایند.<ref name="rfc_2616" /><sup>[بخش ۵٫۱٫۱]</sup>
سرورهای وب موظف هستند حداقل روش‌های GET و HEAD را پیاده‌سازی نمایند.<ref name="rfc_2616" /><sup>[بخش ۵٫۱٫۱]</sup>


=== وضعیت جلسه ===
=== وضعیت جلسه ===
پروتکل انتقال ابرمتن یک پروتکل Stateless می‎باشد. بدین معنی که سرور در یک جلسه هیچ ردی از کاربر ذخیره نمی‎کند. به طور مثال، ''سرور وب هیچگاه نمی تواند به یاد بیاورد که شما در این وبسایت لاگین کرده‎اید یا نه!'' اما به دلیل نیاز شدید نرم‎افزار های تحت وب به ثبت وضعیت، با استفاده از تکنیک‎ها زیر این عمل انجام می‎گیرد:
پروتکل انتقال ابرمتن یک پروتکل Stateless می‌باشد. بدین معنی که سرور در یک جلسه هیچ ردی از کاربر ذخیره نمی‌کند. به طور مثال، ''سرور وب هیچگاه نمی تواند به یاد بیاورد که شما در این وبسایت لاگین کرده‌اید یا نه!'' اما به دلیل نیاز شدید نرم‌افزار های تحت وب به ثبت وضعیت، با استفاده از تکنیک‌ها زیر این عمل انجام می‌گیرد:
* [[کوکی اچ‌تی‌تی‌پی|کوکی]]
* [[کوکی اچ‌تی‌تی‌پی|کوکی]]
* استفاده از متغیر های پنهان در فرم‎های وب
* استفاده از متغیر های پنهان در فرم‌های وب
* استفاده از متغیر های موجود در رشتهٔ درخواست. مانند: index.php?session_id=some_unique_id
* استفاده از متغیر های موجود در رشتهٔ درخواست. مانند: index.php?session_id=some_unique_id


== کدهای وضعیت ==
== کدهای وضعیت ==
از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان ''خط وضعیت'' شناخته شده است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان ''کد وضعیت'' شناخته می‎شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان ''علت وضعیت'' شناخته می‎شود، می‎باشد. نحوهٔ برخورد [[عامل کاربر]] با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‎باشد. زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‎ها برای شناسایی نوع کلی کد استفاده می‎کنند. <ref name="rfc_2616" /><sup>[بخش ۶٫۱]</sup>
از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان ''خط وضعیت'' شناخته شده است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان ''کد وضعیت'' شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان ''علت وضعیت'' شناخته می‌شود، می‌باشد. نحوهٔ برخورد [[عامل کاربر]] با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد. زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند.<ref name="rfc_2616" /><sup>[بخش ۶٫۱]</sup>


کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‎شوند:
کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند:
* کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‎شوند. این گروه، این پیام کلی را مشخص می‎کنند: «''درخواست شما دریافت شد، ادامه دهید''».
* کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‌شوند. این گروه، این پیام کلی را مشخص می‌کنند: «''درخواست شما دریافت شد، ادامه دهید''».
* کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‎شوند. یعنی «''درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده است''».
* کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‌شوند. یعنی «''درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده است''».
* کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‎شوند. یعنی «''کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است''».
* کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‌شوند. یعنی «''کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است''».
* کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‎شوند. این گروه از کدها مشخص می‎کنند که «''کلاینت در درخواست خود اشتباه کرده و یا باعث بروز خطا شده است''».
* کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‌شوند. این گروه از کدها مشخص می‌کنند که «''کلاینت در درخواست خود اشتباه کرده و یا باعث بروز خطا شده است''».
* کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‎شوند. با این مفهوم که «''سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده است''».
* کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‌شوند. با این مفهوم که «''سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده است''».


''علت وضعیت'' هایی که در متن تعریف پروتکل آمده‎اند پیشنهادی بوده و می‎توانند با متون دیگر، به صلاحِ دید [[توسعه دهنده]]، تغییر پیدا کنند. این عبارت می‎تواند توسط [[عامل کابر]] به عنوان توضیحات اضافی به کاربر نمایش داده شود.
''علت وضعیت'' هایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید [[توسعه دهنده]]، تغییر پیدا کنند. این عبارت می‌تواند توسط [[عامل کابر]] به عنوان توضیحات اضافی به کاربر نمایش داده شود.


== مثال ==
== مثال ==
خط ۷۲: خط ۷۲:
Host: www.wikipedia.com
Host: www.wikipedia.com
{{پایان چپ‌چین}}
{{پایان چپ‌چین}}
در درخواست کلاینت، خط اول روش، [[نشانی وب|نشانی]] و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‎کند. از خط دوم هر خط حاوی یک [[سرآیند اچ‌تی‌تی‌پی|فیلد سرآیند]] {{به انگلیسی|Header Field}} می‎باشد و این فیلدها با یک خط خالی به پایان می‎رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‎سرهم مشخص می‎شود. (r\n\)
در درخواست کلاینت، خط اول روش، [[نشانی وب|نشانی]] و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‌کند. از خط دوم هر خط حاوی یک [[سرآیند اچ‌تی‌تی‌پی|فیلد سرآیند]] {{به انگلیسی|Header Field}} می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‌سرهم مشخص می‌شود. (r\n\)


=== پاسخ سرور ===
=== پاسخ سرور ===
خط ۹۳: خط ۹۳:
</html>
</html>
{{پایان چپ‌چین}}
{{پایان چپ‌چین}}
در پاسخ سرور، خط اول، که خط وضعیت نامیده می‎شود، یکی از وضعیت‎های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‎باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند {{به انگلیسی|Header Field}} پاسخ است. این فیلدها با یک خط خالی به پایان می‎رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‎سرِهم مشخص می‎شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‎شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‎شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.
در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‌باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند {{به انگلیسی|Header Field}} پاسخ است. این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‌سرِهم مشخص می‌شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‌شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.


== جستارهای وابسته ==
== جستارهای وابسته ==

نسخهٔ ‏۲۵ ژوئیهٔ ۲۰۱۶، ساعت ۰۳:۰۶

مجموعه پروتکل اینترنت
لایه کاربرد
لایه حمل
لایه اینترنت
لایه پیوند

منشور انتقال ابرمتن (به انگلیسی: Hypertext Transfer Protocol) (مخفف انگلیسی: HTTP) یک پروتکل لایهٔ کاربرد (Application Layer) برای سیستم‌های توزیع شده می‌باشد. این پروتکل عمومی علاوه بر استفاده اصلی آن در ابرمتن‌ها در بسیاری از زمینه‌های دیگر کامپیوتری مانند سامانهٔ نام دامنه (DNS) قابل استفاده است. از نسخه اولیه، این پروتکل در وب جهانی استفاده می‌شد و آخرین به‌روز رسانی آن در ماه جون ۱۹۹۹ تحت عنوان «HTTP/1.1» صورت گرفت.[۱]

گسترش این پروتکل بر عهدهٔ نیروی ضربت مهندسی اینترنت (IETF) و کنسرسیوم وب جهان‌شمول (W3C) ) است. این امر در گروه کاری پروتکل انتقال ابرمتن (HTTP Working Group) صورت می‌گیرد.

تاریخچه

تیم برنرز لی، به وجود آورندهٔ وب جهانی

تیم برنرز لی، طراح و پیشنهاد دهنده وب جهانی که اکنون تحت عنوان WWW شناخته می‌شود، برای اولین بار پروتکل انتقال ابرمتن را به همراه ساختار اولیهٔ زبان نشانه گذاری ابرمتن (HTML) در یک وب سرور ساده و یک مرورگر مبتنی بر متن ارائه داد. در این نسخهٔ اولیه تنها روش درخواست (Request Method) موجود GET و تمامی پاسخ ها به زبان HTML بودند.[۲]

اولین نسخهٔ مستند پروتکل انتقال ابرمتن نسخهٔ ۰٫۹ آن بود که در سال ۱۹۹۱ منتشر شد.[۲] دیو راگت، که در سال ۱۹۹۵ گروه کاری پروتکل انتقال ابرمتن (HTTP Working Group) را رهبری می‌کرد، خواستار گسترش این پروتکل شد و نهایتاً نسخه ۱٫۰ تحت عنوان «HTTP/1.0» در سال ۱۹۹۶ به صورت رسمی معرفی شد.[۳][۴]

گروه کاری این پروتکل در ژانویه سال ۱۹۹۷ اولین استاندارد نسخهٔ ۱٫۱ را که در همان زمان توسط بسیاری از مرورگرها پشتیبانی می‌شد[۵]، به صورت رسمی منتشر کرد.[۶] آخرین به‌روز رسانی نسخهٔ ۱٫۱ در جون سال ۱۹۹۹ در درخواست شماره ۲۶۱۶ (RFC 2616) انجام شد.[۱]

ساختار کلی

پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل کلاینت–سرور می‌باشد. برای مثال یک مرورگر وب می تواند یک کلاینت و نرم‌افزار موجود بر روی سرویس‌دهندهٔ وبسایت، یک سرور باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفت‌وگو را آغاز می‌کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‌گذارد و یا عملیات خاصی را انجام می‌دهد. نتیجهٔ این عملِ سرور در بستهٔ پاسخ HTTP برای کلاینت ارسال می‌شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‌باشد.

مرورگر وب یک نمونه از عامل کاربر (به انگلیسی: User Agent) است. از دیگر عوامل کاربر می‌توان به خزندهٔ وب، نرم‌افزار های تلفن‌های همراه و نرم‌افزار های دیگری که به وب متصل شده و از اطلاعات آن استفاده و یا صفحه‌ای را نمایش می‌دهند، اشاره کرد.

پروتکل انتقال ابرمتن یک پروتکل لایهٔ کاربرد است که در مجموعه پروتکل اینترنت طراحی شده و مورد استفاده قرار می‌گیرد. این پروتکل با فرض اینکه لایهٔ حمل (Transport Layer) زیرین آن قابل اعتماد است طراحی شده و معمولاً از پروتکل هدایت انتقال (TCP) به عنوان لایهٔ زیرین استفاده می‌کند. با این حال از این پروتکل بر روی لایه‌های غیرقابل اطمینان نیز استفاده می‌شود. مثلا در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی پروتکل داده‌نگار کاربر (یک پروتکل غیر امن) مورد استفاده قرار می‌گیرد.

منابع HTTP همگی با یک شناسانهٔ یکنواخت منبع (URI) یا به طور مشخص‌تر با یک نشانی وب (URL) آدرس‌دهی و مشخص می‌شوند. تمامی این آدرس‌ها با نشانهٔ http یا https آغاز می‌گردد. از این آدرس‌ها در زبان نشانه‌گذاری ابرمتن به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‌گردد و از آن تحت عنوان پیوند یا لینک یاد می‌شود.

نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال (به انگلیسی: Connection) برای چندین درخواست را دارد. مثلا می‌تواند عکس‌ها، فایل‌های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند. لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته است.

جلسه

در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه (به انگلیسی: Session) گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال (TCP) بر روی یک درگاهِ از پیش تعیین شده بر روی سرور ( معمولا درگاه شماره ۸۰؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی )، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت (به انگلیسی: Status Line) و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.[۱]

یک نمونه از خط وضعیت در پاسخ به یک درخواست مجاز: 

HTTP/1.1 200 OK

روش‌های درخواست

پروتکل انتقال ابرمتن روش‌هایی را برای درخواست تعریف کرده است (به انگلیسی: Request Method)که هر کدام از آن‌ها باعث انجام عمل خاص در سمت سرور می‌شوند. نسخهٔ ۱٫۰ روش‌های درخواست GET، POST و HEAD را دارا بود.[۷][بخش ۸] در نسخهٔ ۱٫۱ پنج روش جدید افزوده شد[۱][بخش ۹]: OPTIONS، PUT، DELETE، TRACE و CONNECT. از آنجایی که عملکرد این روش‌ها به طور کامل تعریف و شرح داده شده است، لذا تمامی مرورگر ها و سرور ها به راحتی می‌توانند این روش‌ها را پیاده‌سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. در تعداد روش‌ها هیچ محدودیتی وجود ندارد. این نکته باعث می‌شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‌ها فعلی آن آسیبی نرساند و آن‌ها را تغییر ندهد. برای مثال در حال حاضر پروتکل WebDAV هفت روش جدید درخواست را تعریف کرده است.[۸]

GET
درخواست نمایش منبعِ درخواست‌داده‌شده را می‌دهد. (این منبع معمولا یک فایل یا پرونده می‌باشد.) این روش فقط اطلاعات را از سرور دریافت می‌کند و نباید هیچ تاثیری بر روی منابع سرور بگذارد.
HEAD
این روش دقیقا مانند روش GET عمل می‌کند با این تفاوت که بدنه پاسخ را نمی‌خواهد. از این روش برای به‌دست‌آوردن فراداده‌های موجود در سرآیند (به انگلیسی: Header) استفاده می‌شود. یکی از استفاده‌های رایج این نوع درخواست، بررسی تغییر یافتن یک منبع است.
POST
در این روش به همراه بستهٔ درخواست اطلاعاتی نیز فرستاده می‌شود. سرور با توجه به نشانی وب (URL) درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‌گرداند. این اطلاعات ارسالی می‌تواند نامِ‌کاربری و کلمهٔ‌عبور، یک نظر بر روی یک مطلب و یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده است، باشد.[۱][بخش ۹٫۵]
PUT
در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‌شود که این منبع را در آدرس موجود در بسته بارگذاری کند. اگر در محلِ درخواست شده قبلا منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد.
DELETE
از سرور درخواست می‌کند که آدرس فرستاده شده را حذف نماید.
TRACE
در این روش سرور اطلاعات ارسال شده را عیناً به کلاینت باز می‌گرداند. (برای بررسی تغییراتی که واسط‌های شبکه بر روی بسته می‌گذارند، از این روش استفاده می‌شود.)
OPTIONS
از سرور تقاضا می‌کند تا روش‌های درخواستِ (به انگلیسی: Request Method) موجود برای نشانی فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‌های درخواست قابل اجرا بر روی سرور می‌توان از نشانی '*' استفاده کرد.
CONNECT
بستهٔ پروتکل ابرمتن را به یک تونل TCP/IP تبدیل می‌کند. این عمل معمولاً برای برقراری ارتباط امن (HTTPS) بر روی یک پراکسی سرور ناامن استفاده می‌شود.[۹]
PATCH
این روش که در سال ۲۰۱۰ به پروتکل افزوده شد، برای ایجاد تغییرات جزیی بر روی منابع استفاده می‌شود.[۸]

سرورهای وب موظف هستند حداقل روش‌های GET و HEAD را پیاده‌سازی نمایند.[۱][بخش ۵٫۱٫۱]

وضعیت جلسه

پروتکل انتقال ابرمتن یک پروتکل Stateless می‌باشد. بدین معنی که سرور در یک جلسه هیچ ردی از کاربر ذخیره نمی‌کند. به طور مثال، سرور وب هیچگاه نمی تواند به یاد بیاورد که شما در این وبسایت لاگین کرده‌اید یا نه! اما به دلیل نیاز شدید نرم‌افزار های تحت وب به ثبت وضعیت، با استفاده از تکنیک‌ها زیر این عمل انجام می‌گیرد:

  • کوکی
  • استفاده از متغیر های پنهان در فرم‌های وب
  • استفاده از متغیر های موجود در رشتهٔ درخواست. مانند: index.php?session_id=some_unique_id

کدهای وضعیت

از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان خط وضعیت شناخته شده است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان کد وضعیت شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان علت وضعیت شناخته می‌شود، می‌باشد. نحوهٔ برخورد عامل کاربر با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد. زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند.[۱][بخش ۶٫۱]

کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند:

  • کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‌شوند. این گروه، این پیام کلی را مشخص می‌کنند: «درخواست شما دریافت شد، ادامه دهید».
  • کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‌شوند. یعنی «درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده است».
  • کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‌شوند. یعنی «کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است».
  • کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‌شوند. این گروه از کدها مشخص می‌کنند که «کلاینت در درخواست خود اشتباه کرده و یا باعث بروز خطا شده است».
  • کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‌شوند. با این مفهوم که «سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده است».

علت وضعیت هایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید توسعه دهنده، تغییر پیدا کنند. این عبارت می‌تواند توسط عامل کابر به عنوان توضیحات اضافی به کاربر نمایش داده شود.

مثال

در زیر مثالی از یک جلسه بین یک کلاینت HTTP و یک سرور HTTP که بر روی www.wikipedia.com قرار دارد، ارائه شده است.

درخواست کلاینت

GET /index.html HTTP/1.1
Host: www.wikipedia.com

در درخواست کلاینت، خط اول روش، نشانی و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‌کند. از خط دوم هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‌سرهم مشخص می‌شود. (r\n\)

پاسخ سرور

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‌باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) پاسخ است. این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‌سرِهم مشخص می‌شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‌شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.

جستارهای وابسته

HTTP
روش‌های درخواست
زمینه‌های سرآیند
کدهای وضعیت

منابع

  • مشارکت‌کنندگان ویکی‌پدیا. «Hypertext Transfer Protocol». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۳۰ فروردین ۱۳۹۲.
  • «وبسایت رسمی نیروی ضربت مهندسی اینترنت». دریافت‌شده در ۳۰ فروردین ۱۳۹۲.
  • «وبسایت رسمی کنسرسیوم وب». دریافت‌شده در ۳۰ فروردین ۱۳۹۲.

پانویس

  1. ↑ ۱٫۰ ۱٫۱ ۱٫۲ ۱٫۳ ۱٫۴ ۱٫۵ ۱٫۶ «RFC 2616 - HTTP/1.1». نیروی ضربت مهندسی اینترنت. جون ۱۹۹۹.
  2. ↑ ۲٫۰ ۲٫۱ «نسخهٔ اولیهٔ HTTP». کنسرسیوم وب.
  3. ↑ «زندگینامهٔ دیو راگر».
  4. ↑ «برنامه‌ریزی گروه کاری HTTP در سال ۱۹۹۵».
  5. ↑ «توضیحات پیشرفت پروتکل انتقال ابرمتن نسل جدید». کنسرسیوم وب.
  6. ↑ گروه کاری پروتکل انتقال ابرمتن (ژانویه ۱۹۹۷). «RFC 2068». نیروی ضربت مهندسی اینترنت.
  7. ↑ «RFC 1945 - HTTP/1.0». نیروی ضربت مهندسی اینترنت.
  8. ↑ ۸٫۰ ۸٫۱ «RFC 5789». نیروی ضربت مهندسی اینترنت. مارچ ۲۰۱۰. تاریخ وارد شده در |تاریخ= را بررسی کنید (کمک)
  9. ↑ «RFC 2817 - Upgrading to TLS Within HTTP/1.1"». نیروی ضربت مهندسی اینترنت. سال ۲۰۰۰. تاریخ وارد شده در |تاریخ= را بررسی کنید (کمک)
برگرفته از «https://fa.wikipedia.org/w/index.php?title=پروتکل_انتقال_ابرمتن&oldid=17681132»