گفتیم بعضی از فیلد های هدر مختص درخواست هستند. در ادامه قصد داریم همین فیلد ها رو معرفی کنیم.
این فیلد نوع رسانه یا media ای که کلاینت به عنوان پاسخ از سرور انتظار داره رو، مشخص میکند که از نوع text باشه، یا از نوع image یا هرچیز دیگه ای .
این "نوع" هم به شکل جفتی تعیین میشه. یعنی چی؟ یعنی مثلا اگر کلاینت image میخواد، باید پسوند تصویر رو هم بگه که jpeg هست، png هست، چی هست؟ که نحوه اعلانش با / است.یعنی image/jpeg. اگر پسوند تصویر خاصی مد نظرش نیست، میتونه به جای ساب تایپ، از * استفاده کنه. بگه imgae/*.
غیر از جفتی "type" / "subtype"، فیلده Accept یک پارامتر دیگه هم داره که بهش میگن q که در واقع همون quality یا کیفیته. حالا این q نقشش چیه؟ الویت ارسال رو برای سرور مشخص میکنه که مقدار دیفالتش برابر با 1 هست.
نوع میتونه، مقادیر مختلف بگیره که با کاما از هم جدا میشن. هر نوع هم یک الویت میتونه بگیره و سرور به ترتیب همون الویت بندی، هرچیزی که پیدا کرد ارسال میکنه.بیاین یک مثال باهم ببینیم.
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
الان مثال بالا داره به سرور میگه که، من یک ریسورس از تو میخوام.الویت اول اینه که این ریسورس به شکل یک فایل متنی با پسوند html به من بدی.اگر با این نام فایل متنی با پسوند html پیدا نکردی.الویت بعدی ات این باشه که یک فایل متنی با هر پسوندی، ولی با این نام برای من بفرستی. بعدش اگر نداشتی، میتونی به من یک image بدی با تایپ gif. نداشتی یک image بده با پسوند jpeg. نداشتی یک تصویر بده حالا هر چی بود. اگر تصویرم نداشتی، جهنم!، هر چی با این نام در این path ای که بهت دادم که در سطر آغازین پیام میبینی، برای من بفرست!!! یک گلی خودم اینور توی مرورگر، به سرم میگیرم!
اینم مشابه Accept، با این تفاوت که کلاینت اینجا داره در مورد charset های مورد پذیرشش صحبت میکنه.مثلا :
Accept-Charset: utf-8
اینم مثل Accept، با این تفاوت که در مورد انکدینگ charset مورد پذیرشش، داره صحبت میکنه.
اینم مشابه است با Accept، با این تفاوت که در اینجا ما زبان طبیعی که در پاسخ میخواهیم را مشخص میکنیم. مثلا : Accept-Language: da, en-gb;q=0.8, en;q=0.7
خب رسیدیم به Authorization یا احراز هویت.
قبل از اینکه احراز هویت رو بگیم یک نکته ی مهم از پروتکل HTTP باید بدونین و اون اینکه HTTP یک پروتکل StateLess هست. این یعنی چی؟ state یعنی وضعیت و less یعنی کم. و این یک اصطلاحه که مختص HTTP نیست. stateless به معنی عدم نگه داری وضعیته. به زبان ساده، اگر دارین درخواستی به سرور میدین، نمیتونین در اون درخواست، اشاره ای به درخواست های قبلی بکنید! یا از درخواست های قبلی اطلاعاتی بفرستید برای سرور بفرستید.
همه چیز در لحظه است!. چون از وضعیت درخواست های قبلی تون چیزی نگه داری نمیشه.پاسخم به همین شکله. مرورگر درخواست میده.سرور پاسخ میده و تمـــــــام!
نقطه سره خط!.
توی درخواست 10 ام نمیشه چیزی از درخواست 1 ام گفت.چون درخواست 1 پرونده اش به کل بسته شده.منظور از Stateless یعنی این.
حالا با این تصور وارد احراز هویت بشیم.
احراز هویت یعنی شما باید ثابت کنید که کی هستید. این اثبات هم با ثبت نام کردن یا ورود پیدا کردن از طریق نام کاربری و پسورد اتفاق می افته. وقتی کلاینت درخواست میده برای URL ای که احتیاج به احراز هویت داره، سرور در جواب کد 401 رو بهش میده. همونجا که داره پیغام 401 میده یک سرآیند یا هدر فیلدی به نام WWW-Authenticate را هم پر میکنه که در واقع به مرورگر میگه باید احراز هویت ات به این شکلی باشه که من بهت میگم.و اینجا دیگه کلاینت مجبوره که این فیلد رو پر کنه.یعنی چاره ای نداره که در درخواست بعدی، فیلد Authorization رو مطابق با همون چیزی که سرور توی WWW-Authenticate بهش گفته، پر کنه و بفرسته. حالا این فیلد چه مقادیری میگیره؟
ما چند مدل احراز هویت داریم در HTTP.
یک مدل Basic که ساده ترین، عمومی ترین و نا امن ترینشونه.
مدل Basic مطابق تصویر بالاست.یعنی اول درخواست میره.بعد سرور میگه 401 و همونجا WWW-Authentication رو برابر با Basic قرار میده. میتونه پارامتر Realm داشته باشه یا نداشته باشه. بعد User Agent یا حالا ساده تر بگیم، مرورگر، میاد Username و Password رو معمولا بر اساس یک رمزگذاری بر پایه Base64 که یک روش هش کردن داده است، هش میکنه و میفرسته برای سرور.برای مثال:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
و در پاسخ یا 200OK میگیره.یا سرور بهش میگه 403 که یعنی Forbiden.
علاوه بر Basic، یک مدل دیگه هم داریم که بهش میگیم Digest.مدل Digest عملکردش مشابه با Basic هست.فقط یک مقداری امنیت اش بالاتره و اون بیشتر به خاطر اینه که علاوه بر هش کردن ساده، قبلش از الگوریتم های کد گذاری که بر مبنای درهم سازی، برای بالا بردن امنیت هم استفاده میکنه. این الگوریتم ها هم معمولا با SHA نامگذاری میشن.
در مدل Digest، سرور یک مقداری به اسم nonce به کلاینت میده. که در نهایت این مقدار به شکلی کد گذاری شده دوباره به سرور داده میشه با این تفاوت که الگوریتم هم ذکر میشه
روالشون اینه که میان یک سری اطلاعات دیگه غیر از Username و پسورد رو هم درگیر میکنند و انگار دو بار هش کردن داده دارند که دستیابی به اطلاعات رو به نسبت Base64 سخت تر میکنه.
یک نمونه دیگه هم بر اساس یک قرارداد بین کلاینت و سرور هست که بهش میگن توکن.
خیلی بحث طولانی ای داره و شاید در این مجال نگنجه و اگر عمری باشه در بحث های دیگه اگر راجع به JWT خواستم بگم اشاره کنم.توی HTTP نمیشه این بحث رو باز کرد. اما به زبان ساده بگم که ما مفهومی داریم تحت عنوان توکن یا Token. این چی هست؟ این یک قرارداد بین سرور و کلاینته که بعد از اولین لاگین ساخته میشه.وقتی من لاگین کردم یک رشته ای به اسم توکن برام ساخته میشه که این رو هم منه کلاینت و هم سرور نگه میداره. تا کی؟ . دفعه های دیگه من همیشه در فیلد Authorization، اون توکن رو با تایپ Bearer میفرستم. البته حتما تایپ اش نباید Bearer باشه.میتونه یک تایپ دیگه بگیره.
این هدر فیلد چون در همه مرورگرها عمومیت نداره بهش خیلی نمیپردازیم.
این هدر فیلد جلوش به عنوان ولیو یک ایمیل میاد. ایمیل شخصی و کاربری. برای یوزر ایجنت های ربات کاربرد داره.
این هدر فیلد که مشخصه کارش چیه.هاستی که داره درخواست به سمتش میره رو مشخص میکنه.
خب این فیلد هم نکته ی جالبی داره و راهی هست برای کارآمد کردن حافظه ی نهان یا همون Cache سمت کلاینت.بیایم قبل از اینکه بگیم چطوری، ETag رو معرفی کنیم:
وب سرور میاد به ریسورس های یک URL یک مقدار Identifier یا همون شناسه به اسم ETag میده. هر تغییری در اون ریسورس، ETag اش رو هم عوض میکنه. حالا اگر درخواستی از کلاینتی بیاد، که توش اومده این هدر فیلد If-Match رو با مقدار یک ETag پر کرده باشه، اون وقت سرور چک میکنه که اگر ETag با ETag خودش همخوانی داشته باشه، دیگه پاسخ کامل نده که پهنای باند رو اشغال کنه و به کلاینت اجازه میده از حافظه ی نهان خودش استفاده کنه.
این بر خلاف بالاییه.یعنی زمانی که مطابقتی رخ نده، سرور متد درخواست رو اعمال میکنه.
این درخواست رو در صورتیکه با تاریخ یا زمانی که برای تغییرات گذاشته مطابقت بکنه، متدش رو اعمال میکنه.
این هدر فیلد یک مقداری رو به شکل بازه میگیره. بعد اگر همخوانی داشته باشه که سرور استاتوس کد 206 برمیگردونه و درخواست رو اعمال میکنه. اگر همخوانی نداشته باشه کل ریسورس یا محتوا رو برمیگردونه.
نمونه ای از این هدر فیلد رو که برای ما ملموس تره، دانلوده!.
فرض کنید دارید یک فایل رو دانلود میکنید.اولین بار درخواستی دادید و سرور داره با متد GET به شما پاسخ میده.بعد ارتباطتتون قطع میشه.اگر محتوای دانلودی شما از قابلیت دانلود چند قسمتی برخورددار باشه، دوباره که اتصال برقرار بشه از سر نو غرل خانوم کل محتوا رو سرور نمیفرسته، بلکه اگر Resume بزنین، این هدر فیلد If-Renge یک مقداری به سرور میده که سرور اگر بتونه اون مقدار رو پردازش کنه، مابقی ریسورس با استاتوس کد 206 یا Partial Content به شما میده.
این برعکس تگ if-Modified-Since است.
این هدر فیلد فقط و فقط زمانی کاربرد داره که ما از متد TRACE استفاده کنیم. حالا داستان چیه؟ مقدار این فیلد یک عدد اینتیجره.مثلا 10.بعد این درخواست سره هرراه خودش از پروکسی سروری یا ... ای رد بشه یکی از مقدارش کم میشه و سرور زمانی پاسخ 200 OK میده که وقتی درخواست به دستش میرسه، مقداره این فیلد 0 شده باشه و اونجاست که محتوا رو برمیگردونه.
شاید نمیدونم.من از خودم حدس میزنم.شاید برای بحث های امنیتی شبکه مفید باشه.چون میشه فهمید درخواست از مسیر خودش یا مسیر قابل پیش بینی ما یا مورد انتظاره ما خارج شده و به دست یک پروکسی سرور دیگه رسیده که یک مقدار بیشتر ازش کم شده و دیگه 0 نیست.
