احتمالا تا به حال نام HTTP را زیاد شنیده اید. این کلمه مخفف Hypertext Transfer Protocol است و پروتوکل انتقالی بین سیستم های مختلف به حساب می آید. در واقع HTTP پایه اصلی وب به حساب می آید. به همین خاطر لازم است که شما به عنوان یک توسعه دهنده وب درک کاملی نسبت به آن داشته باشید.
قصد داریم طی مقاله ای دو قسمتی در دریای HTTP تنی به آب بزنیم و با مبانی آن آشنا شویم. پس اگر به این موضوع علاقمند هستید ادامه مطلب را از دست ندهید.
«اچ تی تی پی» اجازه برقراری ارتباط بین سرورها و کلاینت های (بخوانید
کاربران) مختلف را فراهم می کند و از شبکه ها با ساختارهای متنوع پشتیبانی
کرده است.
برای رسیدن به چنین انعطاف پذیری «اچ تی تی پی» کار زیادی به ساختار سیستم
شما ندارد و در هر تبادل پیام شامل یک درخواست و پاسخ می شود که ارتباطی با
درخواست و پاسخ قبلی ندارد. به این نوع روش ارتباطی
Stateless
می گویند که البته موضوع صحبت امروز ما نیست.
ارتباط «اچ تی تی پی» معمولا روی پورت ۸۰ برقرار می شود اما می توان از هر
روش انتقالی دیگری هم استفاده نمود و پورت مورد استفاده هم قابل تغییر است.
همانطور که گفتیم ارتباط بین هاست (سرور) و کلاینت (مثلا کامپیوتر کاربر)
معمولا به صورت یک جفت درخواست/پاسخ صورت می گیرد. به این معنی که کلاینت
یک «درخواست اچ تی تی پی» ارسال می کند و یک «پاسخ اچ تی تی پی» دریافت می
نماید.
نسخه فعلی «اچ تی تی پی» که در حال حاضر مورد استفاده قرار می گیرد
HTTP/1.1 است که نسبت به نسخه 1.0 تعدادی خصوصیت ویژه به آن اضافه شده است.
URL ها
همانطور که گفتیم آغاز ارتباط از یک «درخواست اچ تی تی پی» شروع می شود.
این در خواست از طریق Uniform Resource Locators ارسال می شود که به طور
خلاصه به آن URL می گویند. چیزی که قطعا با آن آشنا هستید و به صورت روزانه
از آن استفاده می کنید.
تصویر بالا آناتومی URL را نشان می دهد. می بینید که بسیار ساده است و
البته همیشه URL ها دارای تمام بخش های نمایش داده شده نیستند. اما از این
به بعد با دیدن آنها در آدرس بار مرورگر، می توانید بهتر آنها را درک کنید.
پروتوکل معمولا «اچ تی تی پی» است اما گاهی اوقات هم HTTPS را می بینید که
نشان دهنده ارتباط رمز نگاری شده است. برای اطلاعات بیشتر در این مورد این
مطلب نگهبان را بخوانید:
اس اس ال چیست و چرا توجه به آن بسیار مهم است؟
پورت مورد استفاده معمولا ۸۰ است اما می بینید که در صورت نیاز می توان پورت را تغییر داد.
Verb ها
همانطور که خواندید URL ها مشخص می کنند که قرار است با کدام سرور تبادل
اطلاعات کنیم. اما خود درخواست ما چیست؟ درخواست های کلاینت از طریق HTTP
verb ها مشخص می شوند. این درخواست ها از هاست (سرور میزبان) می خواهد تا
کاری را برایشان انجام دهد. برای مثال یک فایل یا یک صفحه وب را برایشان
ارسال کند.
کلاینت ممکن است درخواست های متنوعی از هاست داشته باشد اما در «اچ تی تی
پی» این Verb ها به تعدادی محدود شده اند که تقریبا در همه جا از همین ها
استفاده می شود. و مشهورترین آنها به این شرح هستند:
- GET : منبع موجود را میگیرد. (در این مقاله هر جا از منبع صحبت کردیم منظور ما چیزهایی مانند فایل، صفحه وب و… است.) در این حالت URL حاوی تمام اطلاعات مورد نیاز برای آقای سرور است تا منبع مورد نیاز را پیدا و آن را ارسال کند.
- POST : یک منبع جدید ایجاد می کند. درخواست های POST معمولا حاوی اطلاعاتی هستند که سبب ایجاد منبعی جدید می شوند.
- PUT : منبع موجود را به روز می کند.
- DELETE : منبع موجود را پاک می کند.
اینها مشهورترین Verb های «اچ تی تی پی» به حساب می آیند. گاهی اوقات PUT و DELETE هم به صورت نسخه های ویژه ای از POST به حساب می آیند و ممکن است در یک درخواست POST قرار گرفته باشند.
در کنار آنها، Verbهای کم مصرف تر اینها به شمار می آیند:
- HEAD : شبیه به GET است. اما بدنه پیام را به همراه ندارد. از آن برای دریافت هدرهای سرور استفاده می شود. برای مثال زمانی که قرار است چک شود منبعی روی سرور تغییر یافته یا نه. (از طریق چک کردن Timestamp یعنی زمان دستکاری شدن منبع)
- Trace : برای پیدا کردن نقاطی است که میان کلاینت و سرور قرار گرفته اند (مثلا کامیپوترها، پروکسی ها و… واقع شده در مسیر) هر کدام از آنها می توانند IP یا DNS خودشان را به هدر ما تزریق کنند. و از آن بیشتر برای عیب یابی استفاده می شود.
- OPTIONS : برای گرفتن مشخصات سرور مورد استفاده قرار میگیرد. کلاینت می تواند با دریافت این اطلاعات درخواستش را به گونه ای تنظیم کند تا توسط سرور پشتیبانی شود.
کدهای وضعیت:
تا اینجا دانستیم که با استفاده از URL ها و Verb ها کلاینت می تواند
درخواست خودش را به سرور ارسال کند. در پاسخ آقای سرور یک «کد وضعیت»
(status code) را به همراه خود پاسخ ارسال می کند.
کدهای وضعیت اهمیت زیادی دارند. چرا که به کلاینت می گویند که پاسخ سرور را
چطور باید معنی کند. این کدها برای هر نوع جوابی دسته بندی شده اند که در
اینجا با آنها آشنا می شویم:
1xx- پیام های اطلاعاتی:
این گروه از کدها که با عدد ۱ شروع می شوند فقط حاوی اطلاعاتی برای کلاینت و
سرور هستند. برای مثال سرور ممکن است این کد را برای کلاینت ارسال کند:
100-continue message و این کد به کلاینت می گوید که درخواستش را دوباره
ارسال کند.
2xx - موفق:
این کد به کلاینت اعلام می کند که درخواست با موفقیت اجرا شده است. مشهور
ترین آن کد: 200 OK است. که در پاسخ به یک درخواست GET ارسال میشود. در
بدنه پیام هم سرور پاسخ را ارسال می کند.
برخی کدهای دیگر در این خانواده به این شرح هستند:
- 202: پذیرفته شده. درخواست پذیرفته شده اما ممکن است در بدنه پاسخ حاوی منبع درخواستی نباشد.
- 204: بدون محتوا. بدنه پیام خالی است و محتوایی در آن قرار ندارد.
- 205: بازنگری در محتوا. به کلاینت می گوید که وضعیت نمایش داکیومنت را ریست کند.
- 206: بخشی از محتوا. به کلاینت می گوید که پاسخ، فقط بخشی از محتوا را به همراه دارد.
3xx - ریدایرکت:
این به کلاینت می گوید که باید حرکت بعدی را انجام بدهد. معمول ترین آن
رفتن به یک URL دیگر است تا منبع مورد نظر را دریافت کند. مشهورترین آنها
به این شرح اند:
- 301: منبع مورد نظر به طور دایمی جابجا شده و در یک URL جدید قرار دارد.
- 303: به جای دیگری مراجعه کنید. منبع مورد نظر به طور موقت در یک URL جدید قرار گرفته.
- 304: سرور می گوید که منبع مورد نظر تغییر نکرده و کلاینت می تواند از نسخه کش شده خودش استفاده کند. این پاسخ در واقع از تبادل ETag ها مشخص می شود. Enttity Tag در واقع نسخه Hash شده محتوا به حساب می آیند. برای اطلاعات بیشتر در این مورد، دو مقاله نگهبان را مطالعه کنید:
آشنایی با Checksum و کاربردهای آن
همه چیز درباره MD5 یا الگوریتم گوارش پیام
سرور این رقم را با Etag محتوایی خودش مقایسه می کند و اگر تغییری وجود نداشته باشد این کد را صادر می کند.
4xx: خطای کلاینت
این کدها وقتی ایجاد می شوند که سرور فکر می کند خطا از طرف کلاینت ناشی می
شود. مثلا یک درخواست که به منبعی اشتباه ختم می شود. مشهورترین آنها 404
است که می گوید منبع مورد نظر وجود ندارد. اما دیگر کدهای مهم این دسته به
این شرح هستند:
- 400: فرمت درخواست صحیح نیست.
- 401: نیاز به تایید هویت با رمز عبور وجود دارد.
- 403: سرور اجازه دسترسی به منبع مورد نظر را نمی دهد.
- 405: از Verb صحیح در ارسال درخواست استفاده نشده یا سرور از آن پشتیبانی نمی کند.
- 409: تداخل. کلاینت سعی می کند منبعی را دستکاری کند که نسبت به زمان کلاینت، جدیدتر به حساب می آید. این پیام را معمول در درخواست های PUT می بینیم. زمانی که چند نفر روی یک منبع کار می کنند.
5xx: خطای سرور
این گروه از کدها خطا در سرور را هنگام بررسی درخواست نشان می دهد. رایج
ترین آن 500 Internal Server Error است و دو پیام رایج دیگر اینها است:
- 501: سرور از این درخواست پشتیبانی نمی کند.
- 503: زمانی که سرور متحمل فشاری بیش از حد توانایی اش باشد یا به هر علت داخلی دچار مشکل شده است. معمولا در این شرایط سرور قادر به چنین پاسخی هم نمیشود و درخواست با timeout مواجه می شود.
