ابتدا یک مرور جامع بر کل مطلب تا کنون داشته باشیم و بعد ادامه مطلب رو بگیم.
تا اینجا گفتیم که پروتکل ارتباطی حاکم بر وب، HTTP است که یکی از اهداف ایجادش پنهان کردن توزیع شدگی و پیچیدگی های شبکه ای و سخت افزاری از دیده کاربران می باشد و هدف مهم دیگه اش امکان تبادل داده و برقراری ارتباط، بین کامپیوترها در یک فرم استاندارد و مشخص است.
در ادامه گفتیم در یک سمت HTTP، کلاینت با مرورگرش قرار داره و در سمت دیگه اش هم سرور با اپلیکیشن وب سروری(IIS و ...) که روی خودش نصب داره و HTTP بین دو کامپیوتر، در نقشه "سرور" و "کلاینت" داره ارتباط برقرار میکنه. این ارتباط هم فقط و فقط از طریق جُفته "درخواست-پاسخ" اتفاق می افته. یعنی حتما درخواستی باید باشد از سمت کلاینت که HTTP بخواد با سرور ارتباط برقرار کنه، و حتما هم در قبال این درخواست، پاسخی به دست کلاینت میرسونه و این یک قاعده بدون استثناست : هر درخواست، پاسخی هم به همراه دارد.
همچنین گفتیم که URL ای که کلاینت به HTTP پاس میده، زمینه ساز ایجاد درخواست HTTP است. به بیانی بهتر، URL درخواست نیست، ولی برای ایجاد یک درخواست از سمت کلاینت، احتیاج به URL داریم.(شرط ضروری درخواست HTTP، وجود یک URL که درونش Host یا سرور مشخص باشه). که راجع به قسمت های URL هم توضیح دادیم.
در قسمت قبلی هم بیشتر راجع به خود درخواست و پاسخ گفتیم. اشاره کردیم که درون درخواست یک قسمت مهمی وجود داره، تحت عنوان HTTP متد یا فعل. و درون پاسخ هم یک قسمت مهمی وجود داره، تحت عنوان Status code یا کد وضعیت.
الان هم بیشتر میخوایم روی همین درخواست و پاسخ فوکوس کنیم و بیشتر با کاربردشون، کنترل یا هندل کردنشون آشنا بشیم که یواش یواش با پیشروی آموزش ها، با REST و API هم درگیر شیم که مساله ی بسیار مهمیه. یادمون نره که آشنایی با HTTP ربطی به اینکه با چه زبانی کد مینویسین نداره.جزو اصول اولیه بک اند کار شدنه.
لذا صحبت های این قسمت هم در تکمیل قسمت قبلیه، ولی تئوری وارتر و با انسجام بالاتر.
خُب، شروع کنیم:
تا اینجا از درخواست و پاسخ به این نتایج رسیدیم که آدرس یا URL ، میزبان رو درون درخواست مشخص میکنه. HTTP method داره میگه که ما از میزبانمون چی میخوایم که اصلا داریم میریم سر وقتش. میزبان یا همون سرور هم با Status Code به ما میگه که تونسته از پس کاری که ما خواستیم بربیاد یا نه که این نَه هم کلی حرف ها برای ما داره و فقط یک نَه خالی نیست. حتی تونستن اشم حرف های زیادی داره که به ما بگه چطور تونسه!
پس اول یک کمی تئوری وار تر وارد استاتوس کد بشیم:
کلا Status code متشکل شده از یک رنج سه تایی ارقام که رقم اولش مشخص کننده ماهیت اشه.
اگر با 1XX شروع بشه، یعنی کد های Information یا اطلاعاتی.یعنی چی؟ این یعنی سرور درخواست ما رو دریافت کرده و در فهم درخواست هم مشکلی براش پیش نیومده. ولی پاسخی که با 1xx به ما میده، پاسخ نهایی درخواست ما نیست!.سرور فقط با این کد ها، داره از چگونگی و نحوه پردازش درخواست ما در سمت سرور، بهمون اطلاعات میده.
خب کاربرد و هدف این اطلاعات برای چیه؟
یکی از کاربردهاشون اصطلاحا Server check ئه.یعنی قبل از اینکه بدنه ی درخواست فرستاده بشه، یک چک میکنه با یک سری اطلاعات از هدر درخواست که ببینه اصلا رد میشه درخواستتون یا نه. اگر بناست که سرور درخواستی رو رد بکنه، یعنی اصلا بدنه درخواست رو نگاه نمیکنه دیگه. پس اصراری نیست که درخواست از اول با بدنه بره. اگر سرور در ازای هدر گفت 100 Continue، که یعنی تا اینجا مشکلی نداشته درخواست، بعد بدنه ی درخواست تکمیل بشه.( این گروه استاتوس کدها بعد از HTTP 1.0 به وجود اومدند)
اگر 2XX داد، در پاسخ که یعنی Successful. یعنی خطا نداشته.معروفترینشونم که 200 ok.
اگر با 3XX شروع شد، یعنی این درخواستی که بهش دادیم برای انجام شدن نیاز به یک سری اقدامات دیگه داره. اصطلاحا به پیام های گروه 3xx میگن پیام های Redirection.یعنی سرور در فهم درخواست مشکلی نداشته ولی برای انجام درخواست، داره حواله مون میده به چیزهای دیگه ای که به عنوان نیاز انجام درخواستش میخواد.پس بازبینی و بررسی این پیام ها برای ما مهمه.
گروه 4XX یعنی مشکلی در خود درخواست ارسالی کلاینت وجود دارد. حالا یا خطا در خود درخواست هست که آدرس اشتباهه یا Resource ای که ما ادرس دادیم، دیگه وجود نداره و … . یا اینکه اصلا امکان تحقق درخواست به هر شکلی و تحت هیچ عنوانی، وجود نداره و رد شده.
گروه 5XX میشن خطاهای سرور. این یعنی درخواست واضح بوده ولی خود سرور توانایی انجامش رو به هر دلیلی، نداره و خبر از مشکلی در سمت سرور حکایت داره.
--------------------------------------------------------------------------------------------------------------------------------------------------------
پیام های HTTP از 4 بخش تشکیل شده :
1- سطر آغازین که الزامیه و گفتیم مهمترین قسمت اش برای درخواست، HTTP متد ئه و برای پاسخ Status code ئه.
GET /hello.htm HTTP/1.1 (نمونه سطر آغازین در پیام درخواست)
HTTP/1.1 200 OK (نمونه سطر آغازین در پیام پاسخ)
2- بعد از سطر آغازین دوتایی های "فیلد-مقدار" سربرگ یا Header میان. (که الزامی نیستند. میتونند باشند و میتوانند نباشند).
بعضی از این دوتایی ها بین درخواست و پاسخ مشترک هستند.بعضی مختص درخواست هستند.بعضی مختص پاسخ هستند و بعضی اطلاعاتی راجع به Body یا بخش چهارم پیام میدند.
حالا در این قسمت من دوتایی های جنرال رو براتون میگم.
که عبارتند از :
این فیلد در هدر، داره مکانیزمی که برای ذخیره سازی یا caching باید پیروی بشه رو مشخص میکنه.به زبان بهتر، زمان و نحوه کش شدن یک ریسورس رو مشخص میکنه. مثلا فرض کنید یک درخواستی بابت ریسورس یک تصویر داره از سمت کلاینت، به سرور میره و سرور در پاسخ داره این تصویر رو با status code 200ok در سطر آغازین،برمیگردونه. اگر سرور در همون پاسخ، بیاد این فیلده هدر رو هم مقداری برابر با
Cache-Control: max-age=2592000, public
بده. اون وقت کلاینت یا همون مرورگر، میاد این محتویات body پاسخ رو به مدت حداکثر 2592000 ثانیه، نگه میداره یا اصطلاحا کَش میکنه که برای دفعه های بعدی نره از سرور بگیرتش و از حافظه نهان خودش استفاده کنه.
موضوع Cache-Control از موضوعاتی هست که میتونین راجع بهش مطالعه داشته باشین چون میشه با دستکاری خصیصه ها و پیکربندیش، این عمل کش کردن رو کاملا هدفمند و امنیتی تر(احراز هویت) باهاش برخورد کرد.
این فیلد وضعیت کانکشن رو مشخص میکنه. قبلا اشاره کردیم که HTTP از TCP یا UDP(در HTTP 3.0) برای ارتباط شبکه ای خودش استفاده میکنه. حالا سرور و کلاینت میتونند بعد از اولین ارتباط کانکشن tcp باز شده رو نگه دارند(با مقدار دادن Keep-alive به این فیلد) و نبندند تا هر بار به ازای هر درخواست، لازم به برقراری یک کانکشن جدید نباشه.
تاریخ و ساعتی که پیام شکل گرفته رو میگه
این فیلد میتونه اثرات متعددی داشته باشه.اما بیشتر من دیدم برای معکوس سازی Cache-control به کار میره.خودم هم راستش خیلی دقیق راجع بهش نمیدونم.این کاربردش رو دیدم.
این فیلد همونطور که از نامش پیداست برای اطلاعات اضافی که توی درخواست در زنجیره زنجیره درخواست و پاسخ میخوایم استفاده میشه.فرض کنید یک امضای دیجیتال، مازاد بر احراز هویت.یک نمونه از Trailer هایی که میتونه باشه.
این فیلد بیشتر برای رمزگذاری یک جورهایی استفاده میشه.اصطلاحا بهش میگند یک فیلد HOP به HOP ئه.یعنی بین دو نود توافقی میشه.ربطی به خود ریسورس نداره.این رو حتما یادتون باشه.این رمزگذاری روی خود ترنسفر داره اتفاق میافته.اونم فقط بین دو نود.اگر چندین کامپیوتر باشند.هر کدوم میتونند Transfer-Encoding خودشون رو برای نود بعدی قرار بدند.مقدار های یا value های مختلفی داره که در بحث ما خیلی طولانی میشه.خودتون میتونید بیشتر بخونید.
این فیلد همونطور که از اسمش پیداست، برای تغییر نسخه ی HTTP به کار میره یا تغییر پروتکل. معمولا درخواست ارتقا توسط کلاینت میره.ولی گاهی سرور کلاینت رو مجبور به ارتقا میکنه که اینجوری یک ریسپانس به کلاینت میده که مضمونش اینه که پروتکل رو تغییر بده. (426 Upgrade Required) که بعد کلاینت درخواست دیگه ای باید بده.
این سرآیند توسط پروکسی ها پر میشه.بخواین ساده نگاه کنید.یک جورایی کارش رد یابی پیامه که داره از مسیر پروکسی به پیش میره. اصطلاحا پروکسی forward داریم و reverse. پروکسی بخواد پیامی رو تغییر بده کلا پروتکلش رو و ... از این فیلد برای رهگیری پیامش داره استفاده میکنه.
اینم که وضعیت پیام رو میگه.هشدارهایی که در زمان درخواست و پاسخ رخ داده.
این مطلب ادامه داره هنوز و من راجع به فیلد های هدر که مربوط به درخواست و پاسخ هست هم میگم و خواستم این نکته رو هم بگم که من هم مثل شما هنوز در حال یادگرفتنم.خوشحال میشم اگر نکته ای مازاد بر این بود یا اشتباهی من مرتکب شدم در کامنت ها بگین که همه استفاده کنند.
