HTTP Header چیست؟ انواع مختلف هدرهای http و تفاوت آنها

HTTP header یا هدرهای http به مشتری و سرور اجازه میدن اطلاعات اضافه شده رو به صورت درخواست یا پاسخ http منتقل کنند. در هدر HTTP، حروف اصلی یعنی خود http از حروف کوچک تشکیل شده و بعد از حروف هم یک دونقطه (:) و بعد از اون هم دو اسلش (//) آورده میشه. بعد از گذاشتن این علائم دقیقاً پشت هدر http آدرس سایت مورد نظر نوشته میشه.

از زمان‌های خیلی قدیم تا همین چند وقت پیش، عناوین اختصاصی و سفارشی، با پیشوند X مورد استفاده قرار می‌گرفتن. اما در ژوئن 2012 همه چی تغییر کرد و استفاده از پیشوند X منسوخ اعلام شد و دلیلش هم مشکلاتی بود که خیلی وقت‌ها سرورها و مشتری‌ها موقع استاندارد شدن زمینه‌های غیر استاندارد در RFC 6648 باهاش روبرو میشدن و در واقع این خواسته مردم بود که این پیشوندها منسوخ بشن و از این اعتبار خارج بشن. بقیه عناوین اختصاصی سفارشی درباره HTTP header هم در IANA registry ذکر شدن که محتوای اصلی اون در RFC 4229 تعریف شده. IANA یک رجیستری از عنوان های جدید HTTP رو هم ارائه میده.

هدرهای http بر اساس محتوایی که دارن گروه بندی میشن:

• هدرهای عمومی (General headers): هم برای درخواست و هم پاسخ مورد استفاده قرار می‌گیرن، اما هیچ ارتباطی با داده های منتقل شده در متن ندارن.
• هدرهای درخواستی (Request headers): حاوی اطلاعات بیشتری در مورد منبع fetch یا منبع درخواست‌های مشتری‌ها هستن.
• هدرهای پاسخ دهنده (Response headers): اطلاعات بیشتری در مورد پاسخ دارن، مثل مکان یا سرور ارائه دهنده اون.
• هدرهای اطلاعاتی (Entity headers): حاوی اطلاعاتی درباره متن منبع هستن، مثل طول محتوای یا MIME type.

HTTP header ها گاهی هم می‌تونن بر اساس کارکرد proxies گروه بندی بشن. این گروه‌ها بر اساس فاکتورهای پروکسی‌ها کار می‌کنن:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding
• Upgrade.

HTTP Header از نوع end-to-end

نحوه کارکرد این هدرها به این صورته که باید از طرف این هدرها http به گیرنده نهایی پیام ارسال بشه: به سرور برای درخواست یا یه مشتری برای پاسخ دادن. این هدرها نباید توسط پروکسی‌های میانی تغییر کنند و باید توسط حافظه پنهان (caches) ذخیره بشن.

HTTP Header از نوع hop-by-hop

این HTTP header ها فقط برای اتصال در سطح حمل و نقل (transport-level connection) کاربرد دارن و نباید توسط پروکسی ها دوباره انتقال داده بشن و یا توی حافظه پنهان ذخیره بشن. هدرهای hop-by-hop فقط و فقط می‌تونن به وسیله هدرهای عمومی پروکسی Connection تنظیم بشن.

 

HTTP header ها شامل مواردی میشن که دونستن این موارد میتونه کار کردن با اونها رو راحت‌تر کنه. حالا می‌خوایم تمام موارد مربوط به HTTP header رو با هم بررسی کنیم.

روش‌های تایید اعتبار

ساختار هدرهای http به گونه‌ای هست که نیاز به تایید اعتبار دارن. این تاییدها به 4 دسته تقسیم می‌شن:

1. WWW-Authenticate

روش تایید اعتبار برای دسترسی به یک منبع .

2. Authorization

روشی برای تایید اعتبار بین کابر و سرور.

3.Proxy-Authenticate

روشی برای تایید اعتبار منبع اصلی پروکسی.

4. Proxy-Authorization

روشی برای تایید اعتبار بین کاربر با سرور پروکسی.

پنهان شده‌ها یا Caching

یک سری از اطلاعات هم در HTTP Header وجود دارن که به صورت پنهان شده یا Caching هستن:

1. Age

در واقع age به مدت زمان چن ثانیه‌ای گفته میشه که شی در حافظه پنهان پروکسی بوده.

2.Cache-Control

دستورالعمل‌هایی برای مکانیسم‌های ذخیره شده در هدر درخواست و در هدر پاسخ.

3. Expires

تاریخ یا زمان معین شده‌ای که بعد از اون پاسخِ داده شده منقضی در نظر گرفته میشه.

4. Pragma

هدر مخصوص پیاده سازی که در هر جای زنجیره درخواست-پاسخ (request-response chain) ممکنه اثرات مختلفی داشته باشه. معمولاً برای سازگاری معکوس با حافظه پنهان HTTP/1.0 که توی اون هدر Cache-Control هنوز وجود نداره، استفاده میشه.

5. Warning

اخطارهای عمومی درباره اطلاعات در صورت بروز هر گونه مشکلی.

نکاتی در مورد مشتری‌ها

بهتره که همین اولش بهتون یادآوری کنیم که نکاتی که درمورد مشتری‌ها در دنیای HTTP Header ها هست، هنوز کامل نیست و در راه کامل شدن هست. ولی اسناد واقعی رو میشه توی وب سایت گروه کاری HTTP پیدا کرد. اسنادی که تا به امروز جمع آوری شده مواردی هست که الان میخوایم به اتفاق هم بررسی کنیم:

 

1. Accept-CH

سرورها می‌تونن با استفاده از قسمت هدر Accept-CH یا یک عنصر معادل HTML با ویژگی http-Equiv که (HTML5) هست، پشتیبانی از Client Hints رو تبلیغ کنند.

2. Accept-CH-Lifetime

سرورها می‌تونن از مشتری بخوان که مجموعه نکات مشتری رو که مدت زمان مشخصی از اون پشتیبانی میکنه، بخاطر بسپاره تا امکان ارسال نکات مشتری رو در صورت درخواست‌های بعدی به مبدأ سرور رو ([RFC6454]) فراهم کنه.

3. Early-Data

نشون میده که درخواست به داده‌های اولیه منتقل شده.

4. Content-DPR

عددی که نسبت پیکسل‌های فیزیکی به پیکسل های CSS از پاسخ تصویر انتخاب شده رو نشان میده.

5. DPR

عددی که نسبت Pixel Ratio) DPR) فعلی مشتری رو نمایش میده، یعنی نسبت پیکسل‌های فیزیکی به پیکسل‌های CSS (بخش 5.2 از [CSSVAL]) نمای طرح (بخش 9.1.1 از [CSS2]) روی دستگاه.

6. Device-Memory

از لحاظ فنی بخشی از API حافظه دستگاه که این هدر نشون دهنده مقدار تقریبی حافظه RAM هست.

7. Save-Data

یک boolean که نشون دهنده اولویت عامل کاربر برای کاهش استفاده از داده هست.

8. Viewport-Width

عددی که عرض نمای نمایش طرح رو در پیکسل‌های CSS نشون میده. مقدار پیکسل ارائه شده عددی هست که به کوچک‌ترین عدد صحیح زیر (حداکثر) گرد میشه.

اگر Viewport-Width در یک پیام بیش از یک بار رخ بده، آخرین مقدار تمام وقایع قبلی رو لغو میکنه و آخرین Viewport-Width اعتبار داره.

9. Width

قسمت HTTP header درخواست Width عددی هست که عرض منبع مورد نظر رو در پیکسل‌های فیزیکی نشون میده (یعنی اندازه واقعی تصویر). مقدار پیکسل ارائه شده عددی هست که به کوچکترین عدد صحیح زیر (یعنی حداکثر) گرد میشه.

اگه عرض منبع مورد نظر در زمان که درخواست داده میشه مشخص نباشه یا منبع به اندازه عرض نمایشگر نباشه، می‌تونین قسمت عنوان Width رو حذف کنید. اگه Width در یک پیام بیش از یک بار رخ بده، آخرین مقدار همه وقایع قبلی رو لغو میکنه و آخرین Width معتبر هست.

موارد مشروط

 

1. Last-Modified

وجود تاریخ اصلاح خیلی مهمه. از آخرین تاریخ اصلاح منبع برای مقایسه چند نسخه از همون منبع استفاده میشه. دقت اون نسبت به ETag کمتره اما محاسبه اون توی بعضی از محیط ها آسون تره. درخواست های مشروط با استفاده از If-Modified-Since و If-Unmodified-Since بررسی میشن. از این دوتا متغیر برای بررسی تغییر رفتار درخواست استفاده میشه.

2. ETag

یک رشته منحصر به فرد برای شناسایی نسخه منبع. درخواست‌های مشروط با استفاده از If-Match و If-None-Match بررسی میشن. از این دوتا متغیر برای بررسی تغییر رفتار درخواست استفاده میشه.

3. If-Match

این مورد درخواست رو مشروط میکنه و فقط درصورتی که منبع ذخیره شده با یکی از ETag های داده شده مطابقت داشته باشه، روش رو اعمال میکنه.

4. If-None-Match

درخواست رو مشروط می‌کنه و فقط درصورتی که منبع ذخیره شده با هیچ کدوم از ETag های داده شده مطابقت نداشته باشه، روش رو اعمال میکنه. این مورد برای به روزرسانی حافظه پنهان (برای درخواست های ایمن) یا جلوگیری از بارگذاری منبع جدید وقتی که منبع موجود هست استفاده میشه.

5. If-Modified-Since

درخواست رو مشروط می‌دونه و انتظار داره نهاد فقط درصورتی که پس از تاریخ معین اصلاح شده باشه، منتقل بشه. این برای انتقال داده ها فقط زمانی که حافظه پنهان قدیمی هست استفاده میشه.

6. If-Unmodified-Since

درخواست رو مشروط به شرایط میکنه و انتظار داره نهاد فقط درصورتی که بعد از تاریخ معین اصلاح نشده باشه، منتقل بشه. وظیفه اصلی If-Unmodified-Since اینه که از انسجام بخش جدیدی از یک محدوده خاص با موارد قبلی یا پیاده سازی یک سیستم کنترل موقع اصلاح اسناد موجود مطمئن بشه.

7. Vary

چگونگی مطابقت با HTTP header های درخواست رو تعیین میکنه تا تصمیم بگیه که آیا میشه از یک پاسخ پنهان شده به جای درخواست پاسخ جدید از سرور مبدا استفاده کرد.

مدیریت اتصالات یا Connection management

1. Connection

این مورد رو که آیا اتصال شبکه بعد از پایان معامله فعلی هم باز میمونه یا نه رو کنترل میکنه.

2. Keep-Alive

این که چه مدت اتصال مداوم باید باز بمونه رو کنترل میکنه.

تصمیم درباره محتوا

1. Accept

انواع داده های قابل ارسال رو به سرور اطلاع میده.

2. Accept-Charset

وظیفه کدگذاری کاراکترهایی که مشتری درک میکنه رو به عهده داره.

3. Accept-Encoding

الگوریتم کد گذاری، معمولاً یک الگوریتم فشرده سازی هست که میتونه توی منبع ارسالی استفاده بشه.

4. Accept-Language

سرور رو از زبان انسانی که انتظار میره سرور بهش ارسال کنه، مطلع میکنه. این یک نکته‌ایه که لزوماً تحت کنترل کامل کاربر نیست: سرور همیشه باید توجه داشته باشه که یک انتخاب صریح کاربر رو نادیده نگیره (مانند انتخاب زبان از لیست زبان‌های کشورها).

نظارت

1. Expect

انتظاراتی رو نشون میده که برای رسیدگی صحیح به درخواست باید توسط سرور برآورده بشه.

2. Max-Forwards

 

Cookie ها

1. Cookie

حاوی کوکی‌های ذخیره شده HTTP header هست که قبلاً توسط سرور با عنوان Set-Cookie ارسال شده.

2. Set-Cookie

کوکی ها رو از سرور به عامل کاربر ارسال کنید.

3. Cookie2

حاوی کوکی HTTP هست که قبلاً توسط سرور با هدر Set-Cookie2 ارسال شده اما منسوخ شده. به جای اون از کوکی استفاده کنید.

4. Set-Cookie2

کوکی ها رو از سرور برای عامل کاربر میفرسته، اما منسوخ شده. به جای اون از Set-Cookie استفاده کنید.

COR ها

1. Access-Control-Allow-Origin

نشون میده که آیا میشه پاسخ رو به اشتراک گذاشت یا نه.

2. Access-Control-Allow-Credentials

نشون میده که آیا میشه پاسخ درخواست رو وقتی که پرچم اعتبارنامه درسته نشون داد یا نه.

3. Access-Control-Allow-Headers

در پاسخ به درخواست قبل از preflight request برای نشون دادن این که از کدوم HTTP headers میشه موقع درخواست واقعی استفاده کرد، استفاده میشه.

4. Access-Control-Allow-Methods

روش‌های مجاز موقع دسترسی به منبع در پاسخ به درخواست قبل از preflight request رو مشخص میکنه.

5. Access-Control-Expose-Headers

نشون میده که کدوم عناوین رو میشه به عنوان بخشی از پاسخ با ذکر نام اونها در معرض دید قرار داد.

6. Access-Control-Max-Age

نشون میده که نتایج یک درخواست قبل از preflight request میتونه در چه مدت ذخیره بشه.

 

غیر قابل ردیابی

1. DNT

اولویت ردیابی کاربر رو بیان میکنه.

2. Tk

وضعیت ردیابی پاسخ مربوطه رو نشون میده.

دانلودها

Content-Disposition

نشون میده که اگه انتقال منابع باید داخل خط (رفتار پیش فرض بدون هدر) نمایش داده بشه یا اگه مثل یک فایل دانلود بشه، مرورگر باید یک بخش «ذخیره به عنوان…» ارائه بده.

اطلاعات بدنه پیام‌ها

1. Content-Length

اندازه منبع، به تعداد هر ده بایت.

2. Content-Type

نوع رسانه منبع رو نشون میده.

3. Content-Encoding

برای تعیین الگوریتم فشرده سازی استفاده میشه.

4. Content-Language

زبان (های) انسانی رو که برای مخاطبان در نظر گرفته شده، توصیف میکنه. نحوه کارش هم اینطوریه که به کاربر اجازه میده با توجه به زبان ترجیحی خودِ کاربران تفاوت قائل بشه.

5. Content-Location

مکان متناوب برای داده های برگشتی رو نشون میده.

پروکسی‌ها

1. Forwarded

اطلاعات داره از طرف سرویس گیرنده‌های پروکسی به سمت مشتری که وقتی پروکسی در مسیر درخواست درگیر بشه، تغییر میکنه یا از بین میره.

2. X-Forwarded-For

آدرس های IP اصلی مشتری رو که از طریق پروکسی HTTP یا یک توازن کننده بار به وب سرور متصل میشه، شناسایی میکنه.

3. X-Forwarded-Host

میزبان اصلی درخواست شده به وسیله مشتری رو برای اتصال به پروکسی یا متعادل کننده بار شناسایی میکنه.

4. X-Forwarded-Proto

پروتکل (HTTP یا HTTPS) رو شناسایی میکنه که مشتری برای وصل شدن به پروکسی یا تعادل دهنده بار استفاده کرده.

5. Via

پروکسی های جلو و معکوس اضافه میشن و میتونن توی عناوین درخواست و HTTP header های پاسخ ظاهر بشن.

Redirect ها

Location

نشانگر URL برای هدایت به یک صفحه.

در صورتی که کاربر مایل به پذیرش باشه رمز گذاری‌های انتقال رو تعیین میکنه.

3. Trailer

به فرستنده اجازه میده تا قسمت‌های اضافی رو آخر پیام اضافه کنه.

WebSocket ها

1. Sec-WebSocket-Key

2. Sec-WebSocket-Extensions

3. Sec-WebSocket-Accept

4. Sec-WebSocket-Protocol

5. Sec-WebSocket-Version

مشخصات دیگر مربوط به HTTP header

1. Accept-Push-Policy

مشتری می‌تونه با ارسال یک قسمت هدر Accept-Push-Policy توی فسمت درخواست، به الگوریتم، اون چیزی که مد نظرش هست رو بگه.

2. Accept-Signature

مشتری می‌تونه قسمت هدر Accept-Signature رو ارسال کنه تا نشون بده قصد استفاده از همه امضاهای موجود رو داره و نشون بده چه نوع امضایی رو پشتیبانی می‌کنه.

3. Alt-Svc

برای لیست کردن روش‌های جایگزین دستیابی به این سرویس استفاده میشه.

4. Date

شامل تاریخ و ساعت ایجاد پیام هست.

5. Large-Allocation

به مرورگر اعلام میکنه که صفحه در حال بارگیری می‌خواد تخصیص زیادی رو انجام بده.

6. Link

قسمت Link-header یک وسیله برای سریال سازی یک یا چند پیوند در هدرهای http رو فراهم میکنه. از نظر معنایی با HTML برابره.

7. Push-Policy

Push-Policy رفتار سرور رو درمورد فشار موقع پردازش درخواست تعریف میکنه.

8. Retry-After

نشون میده که نماینده کاربری، قبل از درخواست پیگیری، چه مدت باید منتظر بمونه.

9. Signature

قسمت هدر Signature لیستی از امضاها رو برای مبادله ارائه میده که هر کدوم با اطلاعات مربوط به نحوه تعیین صلاحیت و تازه سازی امضا همراه هست.

10. Signed-Headers

قسمت هدر Signed-Headers لیستی مرتب شده از فیلدهای هدر پاسخ رو مشخص میکنه که باید در یک امضا گنجونده بشه.

11. Server-Timing

یک یا چند معیار و شرح برای چرخه درخواست پاسخ داده شده درست میکنه.

12. Service-Worker-Allowed

برای حذف محدودیت مسیر با قرار دادن این هدر در پاسخ اسکریپت Service Worker استفاده میشه.

13. SourceMap

کد رو به یک نقشه منبع پیوند میده.

14. Upgrade

سند RFC مربوط به قسمت هدر Upgrade RFC 7230، بخش 6.7 هست. این استاندارد قوانینی رو برای بروزرسانی یا تغییر به پروتکل دیگه‌ای در ارتباط با سرویس گیرنده فعلی، سرور، پروتکل حمل و نقل تعیین میکنه. مثلاً این استاندارد هدر به مشتری اجازه میده تا از HTTP 1.1 به HTTP 2.0 تغییر پیدا کنه، با این فرض که سرور تصمیم به تایید و پیاده سازی قسمت هدر ارتقا بده. هیچ یک از طرفین مجبور به پذیرفتن شرایط مشخص شده در قسمت عنوان ارتقا نیستن. میتونه توی سرورهای client و هدر سرور استفاده بشه. اگه قسمت هدر Upgrade مشخص باشه، فرستنده باید فیلد هدر Connection رو با گزینه upgrade مشخص شده هم ارسال کنه.

15. X-DNS-Prefetch-Control

به صورت پیش فرض DNS رو کنترل میکنه، یک ویژگی که مرورگرها به طور فعالانه وضوح نام دامنه رو روی هر دو پیوندی که کاربر میتونه انتخاب کنه دنبال کنه و URL ها رو برای موارد ارجاع شده به وسیله سند، از جمله تصاویر، CSS ،JavaScript و غیره انجام میده.

16. X-Firefox-Spdy

17. X-Pingback

18. X-Requested-With

19. X-Robots-Tag

از تگ X-Robots-Tag HTTP برای نشون دادن فهرست شدن یک صفحه وب توی نتایج موتور جستجوی عمومی استفاده میشه. هدر در واقع معادل هست.

20. X-UA-Compatible

به وسیله اینترنت اکسپلورر برای نشان دادن حالت استفاده از سند استفاده میشه.