بخش های اصلی

آموزش HTTP

HTTP – فیلدهای سرآیند (Header Fields)

فیلدهای سرآیند، اطلاعات مورد نیاز درخواست یا پاسخ یا اطلاعاتی راجع به شیءای که در بدنه ی پیام فرستاده شده را فراهم می کنن. سه نوع سرآیند پیامِ HTTP وجود داره:

  • General-header: این نوع فیلدهای سرآیند برای هر دو پیام های درخواست و پاسخ کارایی دارن.
  • Client Request-header: این فیلد سرآیند فقط برای پیام های درخواست کاربرد داره.
  • Server Response-header: این فیلد سرآیند فقط برای پیام های پاسخ کاربرد داره.
  • Entity-header: این فیلدهای سرآیند اطلاعات متا برای entity-body، یا اگه body وجود نداشته باشه، برای منبع شناسایی شده توسط درخواست را تعریف می کنن.

سرآیندهای عمومی

Cache-Control

فیلدِ Cache-Control general-header برای تعیین دستوراتی که تمام سیستم های ذخیره سازیِ حافظه ی نهان باید از آن ها اطاعت کنن، به کار میره. شکل دستوری آن بصورت زیره:

Cache-Control : cache-request-directive|cache-response-directive

یک کلاینت یا سرورِ HTTP می تواند از سرآیند عمومیِ Cache-Control برای تعیین پارامترهای حافظه ی نهان یا برای درخواست برخی از انواع اسناد از حافظه ی نهان، استفاده کنه. دستورات حافظه ی نهان در لیستی تعیین میشن، که عناصر آن با ویرگول از هم جدا میشن. برای مثال:

Cache-control: no-cache

در جدول زیر دستورات مهم درخواست حافظه ی نهان لیست شدن که در درخواست های HTTP کلاینت قابل استفاده هستن:

شماره دستور درخواست حافظه ی نهان و توضیحات
1

no-cache

حافظه ی نهان (cache) نباید بدون اعتبار سنجی با سرور اصلی، از response (پاسخ)، برای پاسخ دادن به درخوست های بعدی استفاده کنه.

2

no-store

حافظه ی نهان نباید چیزی راجع به درخواست های کلاینت یا پاسخ های سرور، ذخیره کنه.

3

max-age = seconds

نشان میده که کلاینت قادر به پذیرش پاسخیِه که در آن age از زمان تعیین شده (به ثانیه) بزرگ تر نباشه.

4

max-stale [ = seconds ]

نشان میده که کلاینت قادر به پذیرش پاسخیِه که تاریخ انقضاش بیش تر از حد باشه. اگه ثانیه ها داده شده باشن، پاسخ نباید با زمانی بیش تر از آن زمان منقضی بشه.

5

min-fresh = seconds

نشان میده که کلاینت قادر به پذیرش پاسخیِه که طول عمر جدید آن کمتر از طول عمر فعلی اش (age) بعلاوه ی زمان تعیین شده در ثانیه، نباشه.

6

no-transform

entity-body (محتوا) را تبدیل نمی کنه.
7

only-if-cached

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

در ادامه دستورات مهم مربوط به پاسخ حافظه ی نهان (cache) آورده شدن که در پاسخ HTTP سرور به کار میرن:

شماره دستورات پاسخ حافظه ی نهان و توضیحات
1

Public

نشان میده که ممکنه پاسخ هر حافظه ی نهانی در حافظه ی نهان ذخیره شده باشه.

2

Private

نشان میده که تمام یا قسمتی از پیام پاسخ برای یک کاربر در نظر گرفته شده و نباید با cache به اشتراک گذاشته شده، در حافظه ی نهان ذخیره بشه.

3

no-cache

حافظه ی نهان (cache) نباید بدون اعتبار سنجی با سرور اصلی، از response (پاسخ)، برای پاسخ دادن به درخوست های بعدی استفاده کنه.

4

no-store

حافظه ی نهان نباید چیزی راجع به درخواست های کلاینت یا پاسخ های سرور، ذخیره کنه.

5

no-transformentity-body

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

6

must-revalidate

حافظه ی نهان باید قبل از استفاده از سند های قدیمی، وضعیت آن ها را بررسی کنه و از آن هایی که منقضی شدن را استفاده نکنه.

7

proxy-revalidate

دستورِ proxy-revalidate مثل دستورِ must—evalidate است با این تفاوت که این دستور به عاملِ حافظه های نهان کاربرِ none-shared اعمال نمیشه.

8

max-age = seconds

نشان میده که کلاینت قادر به پذیرش پاسخیِه که در آن age از زمان تعیین شده (به ثانیه) بزرگ تر نباشه.

9

s-maxage = seconds

بیش ترین عمرِ (age) تعیین شده توسط دستورِ max-age یا سرآیندِ Expires (انقضاء) توسط بیش ترین عمرِ (age) تعیین شده توسط این دستور، بازنویسی میشه. حافظه ی نهانِ (cache) private (اختصاصی)، همیشه دستورِ s-maxage را نادیده میگیره.

Connection

فیلد سرآیند عمومیِ Connection، به فرستنده این امکان را میده تا آپشن هایی که برای ارتباط خاصی مطلوب هستن و نباید در ارتباط های بعدی با پراکسی ها ارتباط برقرار کنن، را تعیین کنه. در ادامه شکل دستوری ساده ی استفاده از سرآیندِ header آمده:

Connection : "Connection"

HTTP/1.1 آپشنِ connectionای به نام “close” برای فرستنده تعریف می کنه تا علامت بده (signal) که این ارتباط بعد از تکمیل پاسخ، بسته خواهد شده. برای مثال:

Connection: close

بصورت پیش فرض، HTTP 1.1 از ارتباطات ماندگار و دائمی استفاده می کنه. در این ارتباطات، بعد از انجام تراکنش ، ارتباط بصورت اتوماتیک بسته نمیشه. از طرف دیگه HTTP 1.0 بصورت پیش فرض ارتباطِ دائمی و ماندگار نداره. اگه یک کلاینتِ 1.0 بخواد از ارتباطات دائمی و ماندگار استفاده کنه، باید به صورت زیر از پارامتری به نام keep-alive استفاده کنه:

Connection: keep-alive

Date

تمام تاریخ/زمان های HTTP، بدون استثنا باید با فرمت گرینویچ (زمانِ (GMT)) نمایش داده بشن. برنامه های HTTP، امکان استفاده از هرکدام از سه نوع نمایشِ تاریخ/زمان زیر را میسر می کنن:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

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

Pragma

فیلد سرآیند عمومیِ Pragma

برای include کردنِ پیاده سازی دستورات خاصی به کار میره که ممکنه در طی زنجیره ای از درخواست/پاسخ ها به هر دریافت کننده ای اعمال بشن. برای مثال:

Pragma: no-cache

تنها دستور تعریف شده در HTTP/1.0، دستورِ no-cache است و این دستور در HTTP 1.1 برای سازگاری با نسخه های قبلی استفاده میشه. هیچ دستور جدیدِ Pragmaیِ دیگه ای در آینده تعریف نخواهد شده.

Traier

مقدارِ فیلد عمومیِ Trailer نشان دهنده ی اینه که مجموعه ی فیلدهای سرآیند داده شده همراه با transfer-coding بخش شده، در قسمتِ trailer پیامی که رمزگذاری شده، وجود دارن. در ادامه شکل دستوریِ فیلد سرآیندِ Trailer را مشاهده می کنین:

Trailer : field-name

فیلدهای سرآیند پیامی که در فیلد سرآیندِ Trailer لیست شده ان نباید شامل فیلدهای سرآیند زیر باشن:

  • Transfer-Encoding
  • Content-Length
  • Trailer

Transfer-Encoding

فیلد سرآیند عمومیِ Transfer-Encoding، نشان دهنده ی اینه که برای انتقال امن پیام میان فرستنده و گیرنده، چه نوع تغییری به بدنه ی آن اعمال شده. این فیلد مثل فیلدِ content-coding نیست، چون transfer-encodingها پراپرتیِ پیام هستن نه پراپرتیِ entity-body (محتوا). شکل دستوری فیلد سرآیندِ Transfer-Encoding در ادامه آورده شده:

Transfer-Encoding: chunked

مقادیرِ transfer-encoding، حساس به حروف هستن.

Upgrade

سرآیند عمومیِ Upgrade  این امکان را به کلاینت میده تا تعیین کنه که چه پروتکل های ارتباطی اضافه ای را پشتیبانی می کنه و مایله در صورتی که سرور هم برای تغییر پروتکل ها، آن ها را مناسب بدانه، از آن ها استفاده کنه. برای مثال

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

فیلد سرآیندِ Upgrade مکانیسم ساده ای برای تراکنش میان HTTP/1.1 و یک پروتکل ناسازگار دیگه، فراهم می کنه.

Via

فیلد عمومیِ Via باید در gatewayها و پراکسی ها برای نشان دادن پروتکل های میانی و دریافت کننده ها استفاده بشه. برای مثال، یک پیام درخواست می تواند از یک عامل کاربرِ HTTP/1.0 به یک پراکسیِ داخلیِ code-named “fred”، که برای فرستادن درخواست به پراکسیِ عمومی (public) در nowhere.con از HTTP/1.1 استفاده می کنه ، فرستاده بشه، که درخواست را با فرستادن آن به سررو اصلی در www.ics.uci.edu تکمیل می کنه. این درخواست توسط www.ics.uci.edu دریافت می شه که می تواند فیلد سرآیندِ Viaای بصورت زیر داشته باشه:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

فیلد سرآیندِ Upgrade مکانیسم ساده ای برای تراکنش میان HTTP/1.1 و یک پروتکل ناسازگار دیگه، فراهم می کنه.

Warning

سرآیند عمومیِ Warning برای نگه داشتن اطلاعاتی اضافی راجع به وضعیت یا تغییرات پیام هایی که ممکنه در پیام اعمال نشده باشن، به کار میره. پاسخ ممکنه بیش از یک سرآیندِ Warning داشته باشه.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

سرآیندهای درخواست کلاینت

Accept

فیلد سرآیندِ درخواستِ Accept برای تعیین برخی از انوع رسانه ای که برای پاسخ قابل پذیرش هستن، به کار میره. شکل عمومیِ دستور آن بصورت زیرِه:

Accept: type/subtype [q=qvalue]

چندین نوع رسانه میتوانند در این لیست قرار بگیرند و با ویرگول از هم جدا بشن و مقدار اختیاریِ qvalue سطح کیفیت قابل قبول برای پذیرش انواعی با مقیاس بین 0 تا 1 را نشان میده. در ادامه مثالی در این مورد آورده شده:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

این مثل می تواند بصورت text/html و text/x-c ترجمه بشه که انواع رسانه ای هستن که ترجیح داده میشن، ولی اگه وجود نداشته باشن، می توانید موجودیتِ (entity) text/x-div را بفرستین و اگه آن هم وجود نداشته باشه می توانید موجودیتِ (entity) text/plain را بفرستین.

Accept-Charset

فیلدِ سرآیند درخواستِ Accept-Charset نشان میده که کدام مجموعه کاراکترها برای پاسخ قابل پذیرش اند. در ادامه شکل عمومی دستور آورده شده:

Accept-Charset: character_set [q=qvalue]

چند مجموعه کاراکتر می توانند لیست بشن و با علامت ویرگول از هم جدا بشن. مقدار اختیاریِ qvalue نشان دهنده ی سطح کیفیت قابل قبول برای مجموعه کاراکترهای با مقیاس بین 0 تا 1 است که ترجیح داده نمیشن. در ادامه مثالی در این مورد آمده:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

اگه در فیلد Accept-Charset مقدار ویژه ی "*" وجود داشته باشه، تمام مجموعه کاراکترها قابل قبول میشن و اگه هیچ سرآیند Accept-Charsetای وجود نداشته باشه، بصورت پیش فرض تمام مجموعه کاراکترها قابل پذیرش اند.

Accept-Encoding

فیلد سرآیند درخواستِ Accept-Encoding شبیه به Accept است با این تفاوت که محدود به content-codingهایِه که برای پاسخ قابل قبول باشن. شکل عمومی دستور آن بصورت زیرِه:

Accept-Encoding: encoding types

مثال هایی در ادامه آورده شده:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

فیلد سرآیند درخواستِ Accept-Language شبیه به Accept است با این تفاوت که محدود به مجموعه زبان های ذاتی است که بعنوان پاسخ برای درخواست ترجیح داده میشن. در ادامه شکل عمومی دستور آورده شده:

Accept-Language: language [q=qvalue]

چند زبان می توانند لیست بشن و با علامت ویرگول از هم جدا بشن. مقدار اختیاریِ qvalue نشان دهنده ی سطح کیفیت قابل قبول برای زبان هایی با مقیاس بین 0 تا 1 است که ترجیح داده نمیشن. در ادامه مثالی در این مورد آمده:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Authorization

مقدار فیلد سرآیند درخواستِ Authorization از تأییدیه هایی تشکیل شده و شامل اهراز هویتِ اطلاعات عامل کاربر برای بخش منابعِ درخواستیِه. شکل عمومی دستور به شکل زیرِه:

Authorization : credentials

تأییدیِه ی HTTP/1.0 شمای صدور مجوزِ پایه ای را تعریف می کنه که پارامترهای صدور مجوزِ آن، رشته ای رمزگذاری شده از نام کاربری:پسورد (username:password) در مبنای 64 است. در ادامه مثالی در این مورد آورده شده:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

مقدار رمزگشایی شده ی مثال بالا معادلِ guest:guest123 است که guest در آن IDیِ کاربرِه و guest123 ، پسوردِه.

Cookie

مقدار فیلد سرآیند درخواستِ Cookie شامل یک جفت نام/مقدار (name/value) از اطلاعات ذخیره شده برای URL است. در ادامه شکل عمومی دستور آمده:

Cookie: name=value

چند cookie می توانند بصورت زیر تعریف بشن و با علامت ویرگول از هم جدا بشن:

Cookie: name1=value1;name2=value2;name3=value3

Exept

فیلد سرآیند درخواستِ Except، مجموعه رفتارهای خاصِ سرورکه کلاینت به آن ها نیاز داره را نشان میده. در ادامه شکل عمومی دستور آمده:

Expect : 100-continue | expectation-extension

اگه سرور درخواستی دریافت کنه که شامل یک فیلدِ Except باشه که حاوی یک expectation-extension باشه که پشتیانی نشه، باید با وضعیتِ 417 (exceptation Faild (انتظارات برآورده نشد)) پاسخ بده.

Form

فیلد سرآیند درخواستِ Form حاوی یک آدرس ایمیل اینترنتیِه برای کاربری (انسان) که درخواست های عاملِ کاربر را کنترل می کنه. در ادامه مثالی ساده در این مورد آورده شده:

From: webmaster@w3.org

ممکنه فیلد سرآیند برای اهداف ورود (logging) و بعنوان ابزاری برای شناسایی منبعی از درخواست های غیر معتبر و ناخواسته به کار برِه.

Host

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

Host : "Host" ":" host [ ":" port ] ;

یک host بدون هیچ اطلاعات پورتِ trailingای، اشاره داره به پورت پیش فرض که 80 است. برای مثال، درخواستی در سرور اصلی برای http://www.w3.org/pub/WWW/ میتواند بصورت زیر باشه:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

فیلد سرآیند درخواستِ If-Match همراه با متد استفاده میشه تا متد را شرطی کنه. این سرآیند، از سرور درخواست می کنه که فقط در شرایطی متد درخواستی را اجرا کنه که مقدار داده شده در این تگ معادل باشه با تگ های موجودیتِ (entity) داده شده که با Etag نشان داده میشن. شکل عمومی دستور بصورت زیرِه:

If-Match : entity-tag

علامت ستاره (*) تمام موجودیت ها (entity) را قابل قبول می کنه و تراکنش فقط در شرایطی که موجودیت (entity) وجود داشته باشه، ادامه پیدا می کنه. در ادامه مثال هایی آمده:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

اگه معادل هیچ کدام از تگ های موجودیت ها پیدا نشه، یا اگه از * استفاده بشه ولی هیچ موجودیتی وجود نداشته باشه، سرور نباید متد درخواستی را اجرا کنه و باید پاسخِ 412 (پیش شرط با شکست مواجه شد (precondition Faild)) را برگرداند.

If-Modified-Since

فیلد سرآیند درخواستِ If-Modified-Since همراه با متد استفاده میشه تا متد را شرطی کنه. اگه URL درخواستی تا پایان زمان تعیین شده در این فیلد تغییری نکنه، سرور موجودیتی را بازنخواهد گرداند؛ در عوض یک پاسخِ 304 (تغییری انجام نشد (not modified))، بدون بدنه ی پیام (message-body) برگردانده خواهد شد.  شکل عمومی دستورِ if-modified-since بصورت زیرِه:

If-Modified-Since : HTTP-date

مثالی از این فیلد در ادامه آمده:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

اگه معادل هیچ کدام از تگ های موجودیت ها پیدا نشه، یا اگه از * استفاده بشه ولی هیچ موجودیتی وجود نداشته باشه، سرور نباید متد درخواستی را اجرا کنه و باید پاسخِ 412 (پیش شرط با شکست مواجه شد (precondition Faild)) را برگرداند.

If-None-Match

فیلد سرآیند درخواستِ If-None-Match همراه با متد استفاده میشه تا متد را شرطی کنه. این سرآیند، از سرور درخواست می کنه که فقط در شرایطی متد درخواستی را اجرا کنه که فقط یکی از مقادیر داده شده در این تگ معادل باشه با تگ های موجودیتِ (entity) داده شده که با Etag نشان داده میشن. شکل عمومی دستور بصورت زیرِه:

If-None-Match : entity-tag

علامت ستاره (*) تمام موجودیت ها (entity) را قابل قبول می کنه و تراکنش فقط در شرایطی که موجودیت (entity) وجود نداشته باشه، ادامه پیدا می کنه. در ادامه مثال هایی آمده:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

اگه معادل هیچ کدام از تگ های موجودیت ها پیدا نشه، یا اگه از * استفاده بشه ولی هیچ موجودیتی وجود نداشته باشه، سرور نباید متد درخواستی را اجرا کنه و باید پاسخِ 412 (پیش شرط با شکست مواجه شد (precondition Faild)) را برگرداند.

If-Range

فیلد سرآیند درخواستِ If-Range همراه با GET شرطی به کار میره، تنها برای درخواست قسمتی از موجودیتی که گم شده، در صورتیکه تغییری نکرده باشه و اگه تغییر کرده باشه برای درخواست تمام موجودیت به کار میره. شکل عمومی دستور بصورت زیرِه:

If-Range : entity-tag | HTTP-date

تگ موجودیت و تاریخ، هر دو برای شناسایی قسمتی از موجودیت که دریافت شده به کار میرن. برای مثال:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

در این جا اگه تا پایان تاریخ داده شده، سند تغییر نکنه، سرور، محدوده ی بایت هایی که توسط سرآیندِ Range داده شدن را برمی گرداند در غیر اینصورت تمام سند جدید را برمی گرداند.

If-Unmodified-Since

فیلد سرآیند درخواستِ If-Unmodified-Since همراه با متد به کار میره تا متد را شرطی کنه. شکل عمومی دستور بصورت زیرِه:

If-Unmodified-Since : HTTP-date

اگه تا پایان تاریخ تعیین شده در این فیلد، منبع درخواستی تغییر نکنه یا اگه سرآیند If-Unmodified-Since وجود نداشته باشه، سرور باید عملیات درخواست شده را اجرا کنه. برای مثال:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

اگه نتیجه ی درخواست شده چیزی به غیر از وضعیت های 2xx یا 412 باشه، باید سرآیندِ If-Unmodified-Since نادیده گرفته بشه.

Max-Forwards

فیلد سرآیند درخواستِ Max-Forwards، مکانیسمی به همراهِ متدهای TRACE و OPTIONS فراهم می کنه تا تعداد پراکسی ها و gatewayهایی که می توانند درخواست را به سرور بعدی بفرستن، محدود بشن. شکل عمومی دستور بصورت زیرِه:

Max-Forwards : n

مقدارِ Max-Forwards، یک عددِ صحیحِ دسیمالِه که زمان باقیمانده برای پیام درخواست، که می تواند فرستاده بشه، را نشان میده و برای خطایابی با متدِ TRACE و جلوگیری از حلقه های بی نهایت، کارآمده. برای مثال:

Max-Forwards : 5

فیلد سرآیندِ Max-Forwards ممکنه برای تمام متدهای تعریف شده در مشخصاتِ HTTP، نادیده گرفته بشه.

Proxy-Authorization

فیلد سرآیند درخواستِ Proxy-Authorization این امکان را به کلاینت میده که خودش را (یا کاربرش را) برای پراکسی که نیاز به اهراز هویت داره، شناسایی کنه. در ادامه شکل عمومی دستور آورده شده:

Proxy-Authorization : credentials

مقدار فیلدِ Proxy-Authorization از اعتبارنامه ای تشکیل شده که شامل اهراز هویت اطلاعات عامل کاربر برای پراکسی و/یا ناحیه ی منبع درخواستیِه.

Range

فیلد سرآیند درخواستِ Range بخشی از محدوده ی درخواست شده از سند را تعیین می کنه. شکل عمومی دستور بصورت زیرِه:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

مقدارِ first-byte-pos در byte-range-spec، byte-offset مربوط به اولین بایت در محدوده را میده. مقدارِ last-byte-pos، byte-offset مربوط به آخرین بایت در محدوده را میده؛ که شامل مکان تعیین شده ی بایت ها میشه. می توانید یک byte-unit را بعنوان یک بایت تعیین کنین. آفست های بایت از صفر شروع میشن. چند مثال ساده در ادامه آورده شده:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

چندین محدوده (Range) می توانند لیست بشن و با علامت ویرگول از هم جدا بشن. اگه اولین رقم در محدوه (ها)ی بایت جدا شده توسط ویرگول، از دست رفته باشه، فرض میشه که محدوده از انتهای سند حساب شده. اگه دومین رقم از دست رفته باشه، محدوده، از بایتِ n تا انتهای سند خواهد بود.

Referer

فیلد سرآیند درخواستِ Referer به کلاینت این امکان را میده که آدرسِ (URI) منبعی که URL آن درخواست شده را تعیین کنه. شکل عمومی دستور بصورت زیرِه:

Referer : absoluteURI | relativeURI

در ادامه یک مثال ساده آورده شده:

Referer: http://www.softskill.ir/http/index.htm

اگه مقدار فیلد، یک URI نسبی باشه، باید نسبت را برای Request-URI تفسیر کنه.

TE

فیلد سرآیند درخواستیِ  TE نشان میده که قادر به پذیرش کدام پسوندهایِ rtansfer-coding در پاسخِه و همچنین نشان میده که قادر به پذیرش فیلدهای trailer در یک transfer-coding بخش شده هست یا نه. شکل عمومی دستور به صورت زیرِه:

TE   : t-codings

وجود کلمه ی کلیدیِ “trailers” نشان دهنده ی اینه که کلاینت قادر به پذیرش فیلدهای trailer در یک transfor-coding بخش شده است و بصورت های زیر تعریف میشه:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

اگه مقدار فیلدِ TE خالی باشه یا این فیلد وجود نداشته باشه، فقط transfer-coding بخش میشه. پیامی که transfer-coding نداشته باشه، همیشه پذیرفته میشه.

User-Agent

فیلد سرآیند درخواستِ User-Agent حاوی اطلاعاتیِه راجع به عامل کاربری که مبدأ درخواستِه. شکل عمومی دستور به صورت زیره:

User-Agent : product | comment

مثال:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

سرآیندهای پاسخ سرور

Accept-Ranges

فیلد سرآیند درخواستِ Accept-Range به سرور این امکان را میده تا محدوده ی درخواست های قابل قبول برای یک منبع را مشخص کنه. شکل عمومی دستور به اینصورتِه:

Accept-Ranges  : range-unit | none

برای مثال سروری که درخواست های byte-range (محدوده ی بایت) را می پذیره ممکنه کد زیر را ارسال کنه:

Accept-Ranges: bytes

سرورهایی که هیچ نوع محدوده ی درخواستی را نمی پذیرن ممکنه کد زیر را بفرستن:

Accept-Ranges: none

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

AGE

فیلد سرآیند پاسخِ AGE، تخمین زمانِ فرستنده از میزان زمانی که از زمان تولید پاسخ توسط سرور مبدأ گذشته را میفرسته. شکل عمومی دستور بصورت زیرهِ:

Age : delta-seconds

مقادیرِ Age، اعداد صحیح غیر منفی هستن که زمان را در واحد ثانیه نشان میدن. در ادامه مثالی ساده آورده شده:

Age: 1030

سرورِ HTTP/1.1، شامل یک حافظه ی نهانِه و باید در هر پاسخی که از طرف حافظه ی نهانش تولید میشه، یک فیلد سرآیندِ Age داشته باشه.

Etag

فیلد سرآیند پاسخِ Etag مقدار فعلی تگِ entity را برای درخواست های مختلف فراهم می کنه. شکل عمومی دستور بصورت زیرِه:

ETag :  entity-tag

تعدادی مثال ساده در ادامه آورده شده:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Location

فیلد سرآیند پاسخِ Location برای تکمیل عملیات، گیرنده را  به مکانی به غیر از URI درخواست شده، هدایت مجدد (redirect) می کنه.  شکل عمومی دستور بصورت زیرِه:

Location : absoluteURI

در ادامه مثالی ساده آورده شده:

Location: http://www.softskill/http/index.htm

تفاوت فیلد سرآیندِ Content-Location با Location، اینه که، فیلدِ Content-Location مکان اصلی موجودیت محصور شده در درخواست را شناسایی می کنه.

Proxy-Authenticate

فیلد سرآیند پاسخِ Proxy-Authenticate باید بعنوان بخشی از پاسخِ 407 (نیاز به اهراز هویتِ پرکسی) مشمول (included) بشه. شکل عمومی دستور بصورت زیره:

Proxy-Authenticate  : challenge

Retry-After

فیلد سرآیند پاسخِ Rety-After برای نشان دادن این که قراره چه مدت سرویسی برای کلاینت درخواست شده در دسترس نباشه، در پاسخِ 503 (سرویس در دسترس نیست) به کار میره. شکل عمومی دستور بصورت زیرِه:

Retry-After : HTTP-date | delta-seconds

مثال ها:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

در مثال دوم، تأخیر، 2 دقیقه است.

Server

فیلد سرآیند پاسخِ Server حاوی اطلاعاتی راجع به نرم افزاریه که سرورِ مبدأ برای اجرای درخواست از آن استفاده می کنه. شکل عمومی دستور بصورت زیرِه:

Server : product | comment

در ادامه مثالی ساده آورده شده:

Server: Apache/2.2.14 (Win32)

اگه پاسخ از طریق پراکسی فرستاده بشه، برنامه ی پراکسی نباید سرآیند پاسخِ Server را تغییر بده.

Set-Cookie

فیلد سرآیند پاسخِ Set-Cookie حاوی جفت نام/مقدارهایی (name/value) از اطلاعاتیِه که برای این URL نگهداری و حفظ میشن.

Set-Cookie: NAME=VALUE; OPTIONS

سرآیند پاسخِ Set-Cookie حاوی نشانه ی (token) Set-Cookie است که با لیستی از یک یا تعدادی از کوکی هایی که با ویرگول از هم جدا شدن دنبال میشه. در ادامه مقادیر مُجازی که می توانند بعنوان آپشن تعریف بشن، آمده:

شماره آپشن و توضیحات
1

Comment=comment

این آپشن برای تعیین هر توضیحی که به کوکی تخصیص داده شده به کار میره.

2

Domain=domain

خصیصه ی Domain مشخص می کنه که domain برای کدام کوکی معتبره.

3

Expires=Date-time

تاریخی که کوکی منقضی خواهد شد. اگه خالی باشه، کوکی، زمانی که بازدیدکننده مرورگر را ترک کنه، منقضی میشه.

4

Path=path

خصیصه ی Path زیرمجموعه ای از URLهایی که این کوکی به آن ها اعمال میشه را مشخص می کنه.

5

Secure

به عامل کاربر دستور میده که کوکی را فقط تحت یک ارتباط امن برگرداند.

در ادامه مثالی از یک سرآیند ساده ی cookie که توسط سرور تولید شده را میبینین:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

فیلد سرآیند پاسخِ Vary مشخص می کنه که موجودیت (entity)، چند منبع داره، بنابراین ممکنه براساس لیست تعریف شده ی سرآیند(های) درخواست متفاوت باشه. شکل عمومی دستور بصورت زیرِه:

Vary : field-name

می توانید چند سرآیند را که با علامت ویرگول از هم جدا شدن تعریف کنین و مقدار ستاره "*" نشان دهنده ی اینه که پارامترهای تعریف نشده، سرآیندهای درخواستی را محدود نمیکنن. در ادامه مثالی ساده آورده شده

Vary: Accept-Language, Accept-Encoding

نام فیلدها حساس به حروف هستن.

WWW-Authenticate

فیلد سرآیند پاسخِ WWW-Authenticate باید حاوی پیامِ 401 (غیرمجاز) باشه. مقدارِ فیلد از حداقل یک چالش تشکیل شده که نشان دهنده ی شَما(ها)ی اهراز هویت و پارامترها قابل اجرا در URI درخواست شده هستن. شکل عمومی دستور بصورت زیرِه:

WWW-Authenticate : challenge

ممکن مقادیر فیلدِ WWW- Authenticate، بیش از یک چالش داشته باشن یا اگه بیش تر از یک فیلد سرآیندِ WWW- Authenticate وجود داشته باشه، خود محتوای چالش می تواند حاوی لیستی از پارامترهای جدا شده توسط علامت ویرگول باشه. در ادامه مثالی ساده در این مورد آمده:

WWW-Authenticate: BASIC realm="Admin"

سرآیند های Entity (موجودیت)

Allow

فیلد سرآیندِ موجودیتِ Allow، مجموعه ای از متدهایی که منبع شناسایی شده توسطِ Request-URI از آن ها پشتیبانی می کنه را لیست می کنه.

Allow : Method

می توانید چندین متد را که با علامت ویرگول از هم جدا شدن، تعریف کنین. در ادامه مثالی ساده آورده شده:

Allow: GET, HEAD, PUT

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

Content-Encoding

فیلد سرآیند موجودیتِ Content-Encoding بعنوان شناساگرِ media-type (نوع رسانه) به کار میره. شکل عمومی دستور بصورت زیرِه:

Content-Encoding : content-coding

Content-Encoding یکی از مشخصه های موجودیت شناسایی شده توسط Request-URI  است. در ادامه مثالی ساده آورده شده:

Content-Encoding: gzip

اگه در یک پیام درخواست، Content-Encoding مربوط به یک موجودیت ، برای مبدأ قابل قبول نباشه، سرور باید با کد وضعیتیِ 415 (عدم پشتیبانی از نوع رسانه)، پاسخ بده.

Content-Language

فیلد سرآیند موجودیتِ Content-Language، زبان اصلیِ مخاطبان مورد نظر را برای یک موجودیت محدود شرح میده.

Content-Language : language-tag

ممکنه چندین زبان برای محتوایی که برای چند مخاطب در نظر گرفته شده، لیست بشه. در ادامه مثالی ساده آمده:

Content-Language: mi, en

هدف اصلیِ Content-Language اینه که به کاربر امکان شناسایی و تمایز موجودیت ها را بر اساس زبان دلخواه کاربر بده.

Content-Length

فیلد سرآیند موجودیتِ Content-Length نشان دهنده ی سایز entity-body (محتوا)یی با عدد دسیمالِ OCTETs است که برای گیرنده فرستاده شده یا در مورد متدِ HEAD، سایزِ entity-body (محتوا)، که قابل فرستادن است، با Get،درخواست میشه.  شکل عمومی دستور بصورت زیرِه:

Content-Length : DIGITS

در ادامه مثالی ساده آورده شده:

Content-Length: 3495

هر Content-Lengthای که بزرگتر یا مساوی صفر باشه، مقداری معتبره.

Content-Location

زمانی که موجودیتی که در پیام محصور شده، از مکانی به غیر از منبع درخواستیِ URI قابل دسترسی باشه، فیلد سرآیند موجودیتِ Content-Location، مکان منبع را برای آن موجودیت تأمین میکنه.

Content-Location:  absoluteURI | relativeURI

در ادامه مثالی ساده آورده شده:

Content-Location: http://www.softskill.ir/http/index.htm

همچنین مقدارِ Content-Location، URI اصلی را هم برای موجودیت تعریف می کنه.

Content-MD5

فیلد سرآیند موجودیتِ Content-MD5، یک MD5 digest را برای موجودیت تأمین می کنه تا صحت پیام را به هنگام رسیدن به مقصد بررسی کنه. شکل عمومی دستور بصورت زیرِه:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

در ادامه مثالی ساده آورده شده:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5 digest، بر اساس محتوای entity-body (محتوا)، محاسبه میشه و شامل Content-encodingهایِه که اعمال میشن نه transfor-encodingهایی که به message-body (بدنه ی پیام) اعمال میشن.

Content-Range

فیلد سرآیند موجودیتِ Content-Range همراه با partial entity-body فرستاده میشه تا تعیین کنه که partial body در کجای entity-body کامل، باید اعمال بشه. شکل عمومی دستور بصورت زیرِه:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

مثال هایی از مقادیرِ byte-content-range-spec با در نظر گرفتن این که موجودیت درمجموع 1234 بایتِه، در ادامه آورده شده:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

وقتی پیامِ HTTP حاوی محتوایِ محدوده ای واحد باشه، این محتوا به همراه سرآیندِ Content-Range انتقال داده میشه و سرآیندِ Content-Length، تعداد بایت های واقعی منتقل شده را نشان میده.  برای مثال،

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Content-Type

فیلد سرآیند موجودیتِ Content-Type نوع رسانه ای را نشان میده که برای گیرنده فرستاده شده یا در مورد متدِ HEAD، نوع رسانه ای که قراره فرستاده بشه و بصورت Get درخواست شده را نشان میده. شکل عمومی دستور بصورت زیرِه:

Content-Type : media-type

در ادامه مثالی آورده شده:

Content-Type: text/html; charset=ISO-8859-4

Expires

فیلد سرآیند موجودیتِ Expires، تاریخ/زمان را در پاسخ هایی که قدیمی (منقضی) شدن، میده. شکل عمومی دستور بصورت زیرِه:

Expires : HTTP-date

در ادامه مثالی آورده شده:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

فیلد سرآیند موجودیتِ Last-Modified، تاریخ و زمان را در سرور مبدأیی که last modified (آخرین تغییر) آن تغییر کرده باشه، نشان میده. شکل عمومی دستور بصورت زیرِه:

Last-Modified: HTTP-date

در ادامه مثالی آورده شده:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
در صورتی که سوال و یا نظری دارید، از بخش نظرات با ما در میان بگذارید.

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد

شما چه نظر و یا سوالی درباره این نوشته دارید؟

مبحث آموزشی

آموزش HTTP

HTTP

پرســیدن سؤال جدید

سؤال های تخصصی خود را از ما بپرسید

تبلیغات

دنبال کردن تلگرام کانال سافت اسکیل

https://telegram.me/softskill_ir

عملیات کاربران

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد