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

'''منشور انتقال ابرمتن''' {{به انگلیسی|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) صورت می‎گیردمی‌گیرد.

[[تیم برنرز لی]]، طراح و پیشنهاد دهنده [[وب جهانی]] که اکنون تحت عنوان 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>{{یادکرد وب |نویسنده = |نشانی= 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 برای کلاینت ارسال می‎شودمی‌شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‎باشدمی‌باشد.

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

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

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

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

در پروتکل انتقال ابرمتن به دنباله‎ایدنباله‌ای از درخواست‎هادرخواست‌ها و پاسخ‎هاپاسخ‌ها جلسه {{به انگلیسی|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>^{[بخش ۸]}

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

; '''GET''': درخواست نمایش منبعِ درخواست‎داده‎شدهدرخواست‌داده‌شده را می‎دهدمی‌دهد. (این منبع معمولا یک [[پرونده (رایانه)|فایل یا پرونده]] می‎باشدمی‌باشد.) این روش فقط اطلاعات را از سرور دریافت می‎کندمی‌کند و نباید هیچ تاثیری بر روی منابع سرور بگذارد.

; '''HEAD''': این روش دقیقا مانند روش GET عمل می‎کندمی‌کند ''با این تفاوت که بدنه پاسخ را نمی‎خواهدنمی‌خواهد''. از این روش برای به‎دست‎آوردنبه‌دست‌آوردن [[فراداده|فراداده‎هایفراداده‌های]] موجود در سرآیند {{به انگلیسی|Header}} استفاده می‎شودمی‌شود. یکی از استفاده‎هایاستفاده‌های رایج این نوع درخواست، بررسی تغییر یافتن یک منبع است.

; '''POST''': در این روش به همراه بستهٔ درخواست اطلاعاتی نیز فرستاده می‎شودمی‌شود. سرور با توجه به [[نشانی وب|نشانی وب (URL)]] درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‎گرداندبرمی‌گرداند. این اطلاعات ارسالی می‎تواندمی‌تواند نامِ‎کاربرینامِ‌کاربری و کلمهٔ‎عبور،کلمهٔ‌عبور، یک نظر بر روی یک مطلب و یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده است، باشد.<ref name="rfc_2616"/>^{[بخش ۹٫۵]}

; '''PUT''': در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‎شودمی‌شود که این منبع را در [[یوآرآی|آدرس]] موجود در بسته [[بارگذاری]] کند. اگر در محلِ درخواست شده قبلا منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد.

; '''DELETE''': از سرور درخواست می‎کندمی‌کند که [[یوآرآی|آدرس]] فرستاده شده را حذف نماید.

; '''TRACE''': در این روش سرور اطلاعات ارسال شده را ''عیناً'' به کلاینت باز می‎گرداندمی‌گرداند. (برای بررسی تغییراتی که واسط‎هایواسط‌های شبکه بر روی بسته می‎گذارند،می‌گذارند، از این روش استفاده می‎شودمی‌شود.)

; '''OPTIONS''': از سرور تقاضا می‎کندمی‌کند تا روش‎هایروش‌های درخواستِ {{به انگلیسی|Request Method}} موجود برای [[نشانی وب|نشانی]] فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‎هایروش‌های درخواست قابل اجرا بر روی سرور می‎توانمی‌توان از نشانی '*' استفاده کرد.

; '''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" />

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

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

* استفاده از متغیر های پنهان در فرم‎هایفرم‌های وب

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

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

* کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‎شوندمی‌شوند. این گروه، این پیام کلی را مشخص می‎کنندمی‌کنند: «''درخواست شما دریافت شد، ادامه دهید''».

* کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‎شوندمی‌شوند. یعنی «''درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده است''».

* کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‎شوندمی‌شوند. یعنی «''کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است''».

* کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‎شوندمی‌شوند. این گروه از کدها مشخص می‎کنندمی‌کنند که «''کلاینت در درخواست خود اشتباه کرده و یا باعث بروز خطا شده است''».

* کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‎شوندمی‌شوند. با این مفهوم که «''سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده است''».

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

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

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