فهرست سرآیندهای پروتکل انتقال ابرمتن

سرآیندهای پروتکل انتقال ابرمتن یا فیلدهای سرآیند (به انگلیسی: HTTP Header Fields) جزئی از پیام‌های ارسالی و دریافتی در پروتکل انتقال ابرمتن می‌باشند. این فیلدها پارامترهای یک ارتباط در این پروتکل را مشخص و مقداردهی می‌کنند.

HTTP
روش‌های درخواست
زمینه‌های سرآیند
  • Cookie
  • ETag
  • Location
  • HTTP referer
  • DNT
  • X-Forwarded-For
کدهای وضعیت

قالب کلی

فیلدهای سرآیند بعد از خطِ وضعیت (اولین خط هر پیام) ارسال می‌شوند. این فیلدها به صورت متن ساده بوده و دارای یک نام یا کلید و یک یا چند مقدار هستند که با علامت کولون (:) از هم جدا می‌شوند. هر خطِ سرآیند می‌تواند حاوی یک فیلد سرآیند باشد. در واقع در پایانِ هر فیلد سرآیند باید حروف CR و LF قرار بگیرند. این حروف از حروف کنترلی در رایانش هستند که باعث رفتن به خط بعد می‌شوند.[1] باید توجه داشت که مقدار یک فیلد سرآیند می‌تواند خالی نیز باشد. پایان تمامی سرآیندهای ارسال شده با ارسال یک خطِ خالی مشخص می‌شود. مثال زیر تعدادی از سرآیندهای ارسالی مرورگر وب فایرفاکس هنگام تماس با ویکی‌پدیای فارسی را نمایش می‌دهد: (توجه داشته باشید که حروف CR و LF در پایان هر خط قرار دارند اما دیده نمی‌شوند)

Host: fa.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

خطوط طولانی فیلدهای سرآیند می‌تواند به چند خط نیز شکسته شود. حرف فاصله (Space) یا حرف تَب (Tab) در آغازِ یک خط نمایان‌گر این مسئله است که این خط ادامهٔ خط قبلی می‌باشد.[2]

نام فیلد

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

سیستم ثبت‌نام سرآیند توسط آیانا کنترل و مدیریت می‌شود.

سرآیندهای اختصاصی نرم‌افزارها که استاندارد نیستند، براساس یک استاندارد قدیمی با حروف X- آغاز می‌شوند.[3] در ماه جون سال ۲۰۱۲ این استاندارد به دلیل مشکلاتی که سرآیندهایی که بعدها استاندارد می‌شدند به آن‌ها برمی‌خوردند، منتفی گردید.[4] برای مثال سرآیند X-Gzip که برای فشرده‌سازی هم در پیام‌های ارسالی و هم در پیام‌های دریافتی استفاده می‌شد، بعد از استاندارد شدن، باید به Gzip تغییر می‌کرد.

استفاده اجباری از پیش‌وند Downgraded- نیز برداشته شده‌است.[5]

مقدارهای فیلد

تعداد کمی از مقادیر فیلدهای سرآیند (مانند فیلدهای User-Agent, Server و Via) دارای توضیحات خاص و تکمیلی هستند که این توضیحات نیز ضروری نبوده و می‌توانند توسط نرم‌افزارها نادیده گرفته‌شوند.[6]

محدودیت‌های حجم

در تعریف استاندارد هیچ‌گونه محدودیتی برای اندازهٔ یک فیلد یا مقدارِ آن و تعداد فیلدها در نظر گرفته نشده‌است. بااین‌حال بسیاری از نرم‌افزارها به دلایل کاربردی و امنیتی محدودیت‌هایی را اعمال می‌کنند. برای مقال سرور وب آپاچی در نسخهٔ ۲٫۲ حجم هر سرآیند را به‌صورت پیش‌فرض به ۸۱۹۰ بایت محدود کرده‌است. همچنین به صورت پیش‌فرض حداکثر ۱۰۰ سرآیند در یک درخواست قابل قبول است.[7]

فیلدهای درخواست
نام فیلد توضیحات مثال وضعیت
Accept نوع محتویات قابل قبول در پاسخ

Accept: text/plain

 دائمی
Accept-Encoding لیست کدگذاری‌ها و فشرده‌سازی‌های قابل قبول در پاسخ

Accept-Encoding: gzip, deflate

 دائمی
Cache-Control دستورهای مربوط به ذخیره‌سازی در حافظهٔ نهان را مشخص می‌کند. این دستورات باید توسط تمامی نرم‌افزارها و اجزای شبکه اجرا گردند

Cache-Control: no-cache

 دائمی
Connection عامل کاربر چه نوع ارتباطی را ترجیح می‌دهد

Connection: keep-alive

 دائمی
Cookie یک کوکی اچ‌تی‌تی‌پی که قبلاً با سرآیند Set-Cookie ارسال شده‌است.

Cookie: $Version=1; Skin=new;

 دائمی
Host نام دامنه اینترنتی سرور (میزبان مجازی) و شماره درگاه مورد استفاده. شماره درگاه مورد استفاده در صورتی که شمارهٔ درگاه استاندارد برای سرویس باشد، می‌تواند حذف شود. مثلاً برای وبسایت‌ها می‌توان شماره درگاه ۸۰ را حذف نمود.[8] از نسخهٔ ۱٫۱ اچ‌تی‌تی‌پی استفاده از این سرآیند اجباری است. نام دامنه به کوچکی و بزرگی حروف حساس نیست.[9]

Host: fa.wikipedia.org:80
Host: fa.wikipedia.org

 دائمی
User-Agent رشتهٔ مشخص کنندهٔ عامل کاربر

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0

 دائمی

فیلدهای پاسخ
نام فیلد توضیحات مثال وضعیت
Accept-Ranges انواع داده‌های قسمت‌بندی شده قابل پشتیبانی

Accept-Ranges: bytes

 دائمی
Cache-Control نحوه و مدت ذخیره‌سازیِ منبع در حافظهٔ نهان. به واحد ثانیه

Cache-Control: max-age=3600

 دائمی
Connection نحوهٔ مدیریت ارتباط برای اطلاعات بیشتر به اتصال پایا مراجعه کنید

Connection: close

 دائمی
Content-Length حجم بدنهٔ منبع (بدون در نظر گرفتن سرآیندها) به واحد بایت (بایت‌های ۸ بیتی)

Content-Length: 348

 دائمی
Content-Type نوع دادهٔ ارسالی (مانند تصویر، صفحهٔ وب و …)

Content-Type: text/html; charset=utf-8

 دائمی

جستارهای وابسته

منابع
  1. «تفاوت LF و CR». دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  2. «RFC 2616 - Basic Rules Secion». دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  3. «سرآیندهای اچ‌تی‌تی‌پی». HTTP Watch. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  4. «RFC 6648». گروه ضربت مهندسی اینترنت. جون ۲۰۱۲. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  5. «فرایندهای پیام». آیانا. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  6. «RFC 2616 - 14.3». دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  7. «هستهٔ آپاچی». مستندات آپاچی. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  8. «RFC 2616 - Section 14.23». نیروی ضربت مهندسی اینترنت. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
  9. «RFC 1034 - Section 3.1». نیروی ضربت مهندسی اینترنت. دریافت‌شده در ۱۸ سپتامبر ۲۰۱۳.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.