معرفی و بررسی و آشنایی با پروتکل HTTP – قسمت دوم

در ادامه ی مبحث HTTP امروز قصد داریم که در مورد HTTP message ها و HTTP Request ها صحبت کنیم.
همان طور که قبلا هم گفته شد، منظور ازClient ، یک مرورگری می باشد که بتواند ارتباطی با سرور، به منظور ارسال یک یا چند پیام برقرار کند و همچنین ذکر کردیم که در HTTP منظور از Server در واقع یک Web Server می باشد که بتواند درخواست هایی راا که از سمت Client برای برقراری یک ارتباط ارسال می شود به ترتیب پاسخ دهی کند، و از طریق HTTP یک پیامی را تحت عنوان پیام پاسخ یا Response Message به سمت Client ارسال کند.

همان طور که گفته شد، Server از طریق برنامه ای تحت عنوان Web Server اقدام به پاسخ درخواست های Client می کند، دو نمونه از Web Server ها که میتوان گفت معروف تر هستند، عبارت اند از Apache Web Server و Internet Information Service و موارد دیگر.
Apache Web Server یکWeb Serverr می باشد که با سرور هایی که میتنی بر لینوکس می باشد ارتباط برقرار می کند.

Internet Information Server نیز تنها با سرورهایی که مبتنی بر ویندوز می باشند می تواند ارتباط برقرار کنند.

HTTP از Uniform Resource Identifier) URI) برای معرفی منابع یکسان و همچنین برقراری یک ارتباط استفاده می کند.
حال می خواهیم با ساختار یک پیام HTTP یا HTTP Message آشنا شویم،
ساختار HTTP Messages بسیار شبیه به ساختار [Internet mail[RFC5322 و همچنین [MIME[RFC53222 می باشد. این پیام ها شامل درخواست هایی می باشد که از سمت Client به Server فرستاده می شود و از سمت Server هم به سمت Client پاسخی ارسال می شود.
ساختار HTTP Messagee ها به شکل زیر می باشد.

HTTP-message   = <Request> | <Response>

HTTP برای انتقال داده های مورد نیاز درخواست ها و پاسخ هایی ارسال می کند، در واقع از یک پیام با یک قالب کلی که بر اساس RFC822 می باشد، استفاده می کند. این پیام که یک قالب کلی دارد، از بخش های زیر تشکیل شده است که هر کدام را به صورت جداگانه توضیح خواهیم داد.

Start line
Header Fields
Empty Line
Message Body
Message Start Line
ساختار کلی یک Start line بدین شکل می باشد،

Start-line = Request-Line | Status-Line

منظور از Request-Line در این ساختار، پیام و درخواستی در HTTP می باشد که توسط Client به سمت Server ارسال می شود ، و همچنین منظور از Status-Line پاسخی می باشد که توسط Server به Client ارسال می شود. در واقع منظور از Start-Line همان سرویس پاسخ و درخواست HTTP می باشد. در اینجا مثالی ذکر شده:

GET /hello.htm HTTP/1.1

که در اصل Request-Line می باشد، که توسط Client ارسال شده است.

HTTP/1.1 200 OK

و همچنین این پیام هم Status-Line می باشد، که Server پاسخ داده است.
فیلدهای سرآیند (Header Fields)
اطلاعات مورد نیاز مربوط به سرویس های درخواست و پاسخ درHTTP و یا موضوعات ارسالی که در بدنه ی پیام موجود می باشد، از طریق فیلد های سرآیند یا همان Header Fields اراائه می شود. در اینجا چهار نوع از پیام های سرآیند را در HTTP ذکر کردیم.

General-Header
Request-Header
Response-Header
Entity-Header
General-Header
به نوعی می توان گفت که این نوع فیلد ها عام هستند، چرا که هم برای پیام های درخواستی از سمت Client و هم برای پاسخ های ارسالی از سمت Server به عنوان فیلد سرآیند استفاده می شوند.
Request-Header
همان طور که از عنوان سرآیند پیداست، فقط و فقط مخصوص فیلد سرآیند پیام درخواستی می باشد که از طرف Client ارسال می شود.

Response-Header
این فیلد نیز مخصوص فیلد های سرآیند پیام هایی است که از سمت Server به Client پاسخ داده می شود.
Entity-Header
این فیلد اطلاعاتی ارزشمند در مورد محتویات و بدنه ی پیام به ما می دهد ، حتی اگه بدنه ی پیام خالی باشه و هیچ چیزی در داخل آن وجود نداشته باشه، اطلاعاتی در مورد منابع یا منبعی که این پیام را درخواست داده به ما می دهد.
همه ی فیلد های سرآیندی که در بالا ذکر شد، همگی دارای ساختار یکسانی می باشند، که در اینجا ساختار کلی آن را به نمایش گذاشتیم.

message-header = field-name “:” [ field-value ]

چند مثال دیگر در اینجا آوردیم

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: “34aa387-d-1568eb00”
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
 
محتویات پیام Message Body
برای یک پیام HTTP بخش Message Body به صورت Optional و اختیاری می باشد، اما اگر این بخش قابل دسترس باشد، HTTP برای انتقال پیام به Request یا Response که درخواست می دهد نگاه می کند. زمانی که محتویات بدنه تعیین و مشخص میشه، به طور معمول محتویات فیلد های سرآیند Content-Type و طول محتویات پیام نیز مشخص می شود و در نهایت محتویاتی که پیام های Request و Response شامل می شوند را نیز مشخص می کند. به طور کلی میتوان گفت که Message Body به نوعی مشخص کننده ی محتویات پیام، طول پیام و نوع پیام ارسالی و دریافتی می باشد.
متن پیام در سمت کاربر حامل داده های درخواستی از سمت Client همچون ارسال داده های یک فرم ورود اطلاعات یا هر چیزه دیگری میتواند باشد. و همچنین متن پیام در سمت Server می تواند شامل فایل ها ، تصاویر و چیزهای دیگری باشد که به Client پاسخ داده می شود. در اینجا یک نمونه ی ساده از Message Body برای شما ذکر کردیم.
<html>
<body><h1>Hello, World!</h1></bodyy>
</html>
HTTP Requests
در یک سرویس HTTP زمانی که مرورگر یه درخواستی را به سمت Server ارسال می کند، این درخواست را در قالب یک فرمت خاصی ارسال می کند که در زیر به طور کلی به آن اشاره کردیم

A Request-line

Zero or more header (General Request Entity) fields followed by CRLF

An empty line (i.e., a line with nothing preceding the CRLF)
indicating the end of the header fields

Optionally a message-body
در ادامه به توضیح هر یک از این قالب ها خواهیم پرداخت،
درخواست خط Request-Line
Request-Line با یک Method token آغاز می شود به دنبال آن Request-URI و ورژن پروتکل مورد استفاده قرار می گیرد و با CRLF به پایان میرسد.دقت کنید که المان های Request-Line با Space از هم جدا می شوند. در اینجا قالب کلی Request-Line را مشاهده می کنید.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
 در ادامه میخواهیم در مورد هر کدام از بخش های Request-Line نیز توضیحات بیشتری رائه کنیم.
Request Method
بر اساس اطلاعاتی که Request-URI به HTTP می دهد، Request Method نوع کاری(Method) که باید بر روی منابع مشخص انجام شود را مشخص می کند . نکته ای که قابل توجه می باشد، این است که متد هایی که Request method تعیین می کند ، به حروف بزرگ و کوچک حساس می باشد، علاوه بر این باید با حروف بزرگ نوشته شوند تا بتواند آن ها را شناسایی کند.در اینجا لیستی از متدهایی که Request Method از آنها پشتیبانی می کند را لیست کردیم.
GET
متد GET برای بازیابی اطلاعات از سرور داده استفاده می شود، که برای این کار از URI کمک می گیرد. درخواست هایی که از متد GET استفاده می کنند، تنها کاری که باید انجام دهند، بازیابی داده ها می باشد بدین معنا که نباید هیچ گونه اثری بر روی داده ها بگذارد، و تنها کاری که میکند، بازیابی اظلاعات از سرور داده باید باشد.
HEAD
همانند متد GET می باشد با این تفاوت که متد HEAD وضعیت خط (Line) و همچنین بخش سرآیند پیام را نیز انتقال می دهد.
POST
از متد POST برای ارسال اطلاعات به Server استفاده می شود، اطلاعاتی همچون اطلاعات مربوط به مشتری، آپلود فایل و موارد دیگر. متد POST برای ازسال اطلاعات به Server از فرم های ورود اطلاعات HTML استفاده می کند.
PUT
این متد، تمام نمونه های فعلی از منابع هدف را با آپلود کردن محتویات جایگزین می کند.
DELETE
این متد دقیقا برعکس PUT عمل می کند، تمام نمونه های فعلی از منابع هدف را با استفاده از URI پاک می کند.
CONNECT
این متد یک تونل با استفاده از URI به سمت Server شناسایی و ایجاد می کند.
OPTIONS
این متد تعدادی گزینه های ارتباطی را برای منابع هدف توصیف می کند.
TRACE
این متد باعث می شود که کاربر به صورت مرحله به مرحله هر گونه تغییراتی که در روند Request صورت می گیرد را ببیند.
REQUEST-URI
URI مخفف شده ی Uniform Resource Identifier می باشد، بدین معنا که، مشخص کننده ی منابع یکنواخت و یکسان می باشد. در اصل زمانی که یک REQUEST_URI ارسال می شود ، این سرویس صحت و هویت منابعی که در حال ارسال می باشد را بررسی می کند و بر میگرداند.در اینجا نمونه ای از قالب یک URI را ذکر کردیم،
Request-URI = “*” | absoluteURI | abs_path | authority
از علامت ستاره زمانی استفاده می شود که درخواست HTTP ارسالی توسط Client به یک منبع خاص صدق نمی کند و این درخواست تنها توسط server خود HTTP ارسالی صدق کند و قابل شناسایی و خواندن باشد. استفاده از دستور * زمانی مجاز می شود که پیام های ارسالی توسط HTTP با منابع موجود هیچگونه همخوانی نداشته باشد. به عنوان مثال،
OPTIONS * HTTP/1.1
AbsoluteURI
از این دستور زمانی استفاده می شود که به یک پروکسی ساخنه شده، درخواست HTTP داده می شود. حال پروکسی فراخوانی شده، یک درخواست یا سرویسی را به سمت یک کش معتبر(Valid cash) ارسال می کند و در نهایت هم یک پاسخ از طریق همان کش معتبر دریافت می کند. مثالی از absoluteURI،
GEThttp://www.TSMandegar.com/latest?type
به طور کلی شناسایی منبع رایج ترین و اصلی ترین وظیفه ای است که یک Request-URI داردبرای مثال، اگر یک کاربر بخواهد یک منبعی از اطلاعات را به طور مستقیم از سرور مبدا بازیابی کند، باید یک ارتباط TCP با پورت ۸۰ هاست مورد نظرش مثلا www.itpro.ir بسازد، و کدی که در پایین آمده را به آن ارسال کند.
GET/latest?type=videos
Host: www.TSMandegar.com
 
نکته ای که حائز اهمیت است این است که Absolut Path یا همان مسیر یا آدرس کامل نباید خالی باشد، اگر آدرس جاری و کنونی در URL اصلی خالی است و هیچ مقداری ندارد، حد اقل باید با یک علامت “/” پر شود که بتواند آدرس را از ریشه یا همان Root بخواند.

Request Header Fields
بعد از اینکه فیلد های سر آیند HTTP را به طور کامل یاد گرفتیم، در بخش های بعد به طور کامل در مورد کلیت و ماهیت سرآیند ها بحث می کنیم و به طور کامل بررسی خواهیم کرد. خب، حال میخواهیم بدانیم که فیلد های سرآیند درخواست شامل چه چیزهایی می باشد و با مفهموم آن آشنا شویم.فیلدهای سرآیند درخواست یا همان Request Header Fields به کاربر یا همان منبع درخواست این اجازه را میدهد تا یکسری اطلاعات اضافی همچون اطلاعاتی در مورد خود درخواست، یا به طور مثال اطلاعاتی در مورد ارسال کننده درخواست، به سمت سرور با خود حمل کند. به نوعی میتوان گفت که این فیلد ها برای اصلاح درخواست ها به کار می روند. در اینجا لیستی از مهم ترین فیلد های سرآیند درخواست که کاربردی تر هستند را ذکر کردیم.

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forward
Proxy-Authorization
Range
Refer
TE
User-Agent
در پایان هم مثال هایی از Request Message ذکر کردیم.
در مثال اول می خواهیم یک صفحه ی hello.htm را از وب سرور TSMandegar.com به صورت یک درخواست HTTP واکشی کنیم.
 
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.TSMandegar.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
 
در این مثال هیچ گونه درخواست داده به سمت Server ارسال نشد، چون فقط یک صفحه ی HTML ساده را واکشی کردیم.
در این مثال ، Connection یک سرآیند کلی می باشد و باقی سرآیند ها هدر های درخواست هستند.
مثال بعدی نشان میدهد که چگونه اطلاعات یک فرم ورود اطلاعات با استفاده از محتویات پیام درخواست یا Request Message Body به سمت سرور ارسال می شود.
 
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.TSMandegar.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
licenseID=string&content=string&/paramsXML=string
در این مثال نیز آدرس cgi-binprocess.cgi برای پردازش داده های تایید شده استفاده می شود و بر همین اساس یک پاسخی برگردانده می شود.
Content-Type این اطلاع را به ما میدهد که سروری که داده ها را تایید کرده یک Web Form ساده است، همچنین Length طول واقعی داده ها رو داخل بدنه ی پیام Message Body قرار می دهد.