نوشته‌ها

آشنایی با پروتکل HTTP – بخش سوم

آشنایی با پروتکل HTTP – بخش سوم

همان طور که می دانید، زمانی که یک درخواستی از طرف Client به سمت سرور ارسال می شود، سرور به محض دریافت ، باید به آن درخواست پاسخ دهد، حال این درخواست می تواند ، یک پیام تایید باشد یا یک ارور، نکته ای که مهم است این است که در هر صورت یک جواب از سمت سرور به Client ارسال می شود.

HTTP-Response

بعد از دریافت و تفسیر یک پیام درخواست یا Request Message سرور به Request ارسالی، توسط یک پیام پاسخ که Response Message نامیده می شود،به درخواست ارسالی پاسخ می دهد. پیامی که سرور به درخواست کننده یا Client میدهد، به شکل و فرمت زیر می باشد:

A Status-line

Zero or more header (General|Response|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

هر کدام از محتویات مورد استفاده در یک Response-Message شامل توضیحاتی می باشد که در ادامه به بررسی هر یک از آن میپردازیم.

entity-body-new

Message Status-Line
این پیام به نوعی وضعیت کلی خط را به ما نشان می دهد، ساختار آن هم همان طور که در کد زیر پیداست، بدین شکل می باشد که شامل، ورژن پرتکل مورد استفاده در پیام و بدنبال آن یک کد وضعیت نمایش داده می شود که به صورت عددی می باشد و بدنبال آن نیز یک عبارت متنی که به نوعی توضیحاتی در مورد وضعیت خط دریافت می کند نمایش داده می شود. فقط به این نکته هم باید دقت داشت که هر کدام از این بخش ها باید با کاراکتر Space از هم جدا شوند.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP-Version
این فیلد، ورژن پروتکل HTTP می باشد که سرور از آن پشتیبانی می کند .در اینجا مثالی از HTTP-Version آوره شده است.

HTTP-Version = HTTP/1.1

Status Code
این المان، یک کد سه رقمی از نوع عدد صحیح می باشد، اولین رقم آن بیانگر کلاسی از پاسخ ارسالی توسط سرور می باشد، دو رقم آخر این کد، عمل خاصی را انجام نمی دهد. در اینجا برای رقم اول کد پنج نمونه از ارقامی که می پذیرد را ذکر می کنیم.
1XX: Informational
این کد بدین معنا می باشد که درخواست ارسالی دریافت شده است، و پردازش های لازم به روی درخواست در حال انجام می باشد.
2XX: Success
این کد بدین معنا می باشد که پیام ارسالی با موفقیت دریافت شده و کاملا واضح و قابل درک بوده و همچنین پیام پذیرفته شده است و مشکلی وجود نخواهد داشت.
3XX: Redirection
این کد، بدین معنا می باشد که، برای تکمیل درخواست، باید مجددا درخواست مورد نظر ارسال شود.
4XX: Client Error
این کد بدین معنا می باشد که، درخواست ارسالی از نظر ترکیب و فرمت دارای اشکال می باشد و صحیح نمی باشد یا اینکه کلا پیام درخواست تکمیل شدنی نیست و نمی توان پردازش مورد نظر را بر روی آن انجام داد.
5XX: Server Error
این کد بدین معنا می باشد که ، درخواستی که ارسال شده است، ظاهرا مشکلی ندارد، اما سرور قادر به پاسخ گویی به آن نمی باشد.
نکته ای که حائز اهمیت می باشد، این است که ، کد های وضعیت HTTP بسیار گسترده هستند ، با این حال برنامه ها و توسعه دهنده های HTTP الزاما نباید مفهوم همه ی کد های ثبت شده را بدانند. مبحث کد های وضعیت HTTP در بخش های بعدی به طور جداگانه بررسی خواهد شد.
فیلد های سرآیند پاسخ(Response Header Fields)
فیلد های سرآیند پاسخ، این اجازه را به سرور می دهند، که یک سری اطلاعات اضافی که تنها جنبه ی توضیحی از Response ارسالی توسط Server را دارند،به همراه پیام ارسالی به سمت Client ارسال کند. مشخصه و ویژگی منحصر به فرد این اطلاعات اضافی این است که هیچ فضایی از خطوط ارسالی را اشغال نمی کنند.این فیلد های سرآیند،اطلاعاتی در مورد سرور و همچنین اظلاعاتی در مورد دسترسی های بیشتر به منابعی که توسط درخواست های URI شناسایی شده است ، به ما می دهند.
مثال هایی از پیام های پاسخ(Response Message)
مثال زیر نحوه ی اضافه کردن یک صفحه ی Hello.htm از یک Web Server به روی یک صفحه ی درحال اجرا را نشان می دهد.

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

در مثال زیر یک صفحه ای نمایش داده شده است که حاوی متن Error می باشد، که دلیل بروز این Error پیدا نشدن صفحه ی درخواستی توسط Clientمی باشد، این Error از طرف Web Server ارسال می شود.

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

مثال زیر نمایانگر یک Error می باشد که، علت بروز آن، ناشناس بودن ورژن HTTP درخواستی می باشد.

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.</p>
<p>The request line contained invalid characters following the protocol string.</p>
</body>
</html>

HTTP-Method

Request Method نوع کار یا (Method) که باید بر روی منابع مشخص انجام شود را مشخص می کند . نکته ای که در بحث Request Method باید به آن توجه داشت، این است که متد هایی که Request method تعیین می کند ، به حروف بزرگ و کوچک حساس می باشد، علاوه بر این باید با حروف بزرگ نوشته شوند تا بتواند آن ها را شناسایی کند.در اینجا توضیح مختصری از متدهایی که Request Method از آنها پشتیبانی می کند را ذکر کردیم.

GET Method 

متد GET برای بازیابی اطلاعات از سرور استفاده می شود، که برای این کار از URI کمک می گیرد. درخواست هایی که از متد GET استفاده می کنند، تنها کاری که باید انجام دهند، بازیابی داده ها می باشد بدین معنا که نباید هیچ گونه اثری بر روی داده ها بگذارد، و تنها کاری که میکند، بازیابی اظلاعات از سرور داده باید باشد. در اینجا مثالی از نحوه ی ایجاد صفحه ی hello.htm توسط متد Get را ذکر کردیم.

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

 پاسخ سرور به درخواستی که در مثال بالا ذکر شده است را در اینجا می بینید

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
HEAD 
همانند متد GET می باشد با این تفاوت که متد HEAD وضعیت خط یا (Line) و همچنین بخش سرآیند پیام را نیز انتقال می دهد. در اینجا نحوه ی ایجاد فایل سرآیند برای صفحه ی hello.htm را آوردیم
HEAD /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
و همچنین پاسخی که سرور به این درخواست می دهد
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
از این مثال پیداست که سرور بعد از فایل سرآیند هیچگونه اطلاعاتی را ارسال نمی کند.
POST 
از متد POST برای ارسال اطلاعات به Server استفاده می شود، اطلاعاتی همچون اطلاعات مربوط به مشتری، آپلود فایل و موارد دیگر. متد POST برای ارسال اطلاعات به Server از فرم های ورود اطلاعات HTML استفاده می کند. در اینجا نیز یک مثالی ذکر کردیم که برای ارسال داده های یک فرم از متد POST استفاده شده است، که توسط process.cgi پردازش و در نهایت یک پاسخ برگردانده خواهد شد.
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: tsmandegar.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<?xml version=”1.0″ encoding=”utf-8″?>
<string xmlns=”http://clearforest.com/”>string</string>
در اینجا اسکریپت سمت سرور process.cgi داده ها را پردازش کرد و یک پاسخ به عنوان تایید عملیات پردازش ارسال می کند.
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: “34aa387-d-1568eb00”
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>
PUT
این متد، تمام نمونه های فعلی از منابع هدف را با آپلود کردن محتویات جایگزین می کند. در اینجا مثالی ذکر شده که درخواست های دریافتی از سرور را به صفحه ی hello.htm تحویل میدهد تا بتواند آن ها را در پوشه ی root در سرور ذخیره کند.
PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tsmandegar.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
سرور نیز به محض دریافت پیام و آپلود کردن محتویات، یک پاسخ تحت عنوان موفقیت آمیز بودن عملیات به Client ارسال می کند.
HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>The file was created.</h1>
</body>
</html>
DELETE
این متد دقیقا برعکس PUT عمل می کند، تمام نمونه های فعلی از منابع هدف را با استفاده از URI پاک می کند. در مثال زیر سرور برای حذف کردن محتویاتی که در داخل پوشه ی root صفحه ی hello.htm قرار دارد یک پیام درخواست ارسال می کند.
DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
سرور نیز بعد از حذف محتویات درخواستی یک پیام تایید به Client ارسال می کند.
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>
CONNECT
این متد یک تونل با استفاده از URI به سمت Server شناسایی و ایجاد می کند. در مثال زیر درخواست هایی که سرور برای ارتباط با یک هاست میدهد، به طور مثال itpro.ir ، ذکر شده است.
CONNECT www.tsmandegar.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
فرآیند ایجاد کانکشن با سرور مربوط به هاست شرکت پذیرنده و ارسال پیام تایید کانکشن به Client را در اینجا مشاهده می کنید.
HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
OPTIONS
این متد بیشتر برای Client مفید می باشد، تا بتواند به وسیله ی آن متد های HTTP و سایر option هایی که وب سرور از ان ها پشتیبانی می کند را شناسایی و دریافت کند، ممکن است که یک Client بخواهد فقط از یک یا چند متد خاص استفاده کند، یا اینکه از همه ی متد هایی که وب سرور از آن ها پشتیبانی می کند، استفاده کند، که برای اینکار کافیست که از یک علامت ستاره(*) استفاده کند، به مثال زیر توجه کنید:
OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
در پاسخ سرور لیستی از تمامی متد هایی که توانایی پشتیبانی از آن ها را دارد برای ما نمایش می دهد.
TRACE
این متد باعث می شود که کاربر به صورت مرحله به مرحله هر گونه تغییراتی که در روند Request صورت می گیرد را ببیند. در اینجا مثالی از نحوه ی انجام این عمل را ذکر کردیم.
TRACE / HTTP/1.1
Host: www.tsmandegar.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
سرور هم در پاسخ به این درخواست اطلاعات زیر را برای ما لیست می کند.
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Connection: close
Content-Type: message/http
Content-Length: 39TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
.
.
منبع: itpro.ir

آشنایی با پروتکل HTTP – بخش دوم

آشنایی با پروتکل 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 Server می باشد که با سرور هایی که میتنی بر لینوکس می باشد ارتباط برقرار می کند.

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

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

HTTP-message   = <Request> | <Response>

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

  1. Start line
  2. Header Fields
  3. Empty Line
  4. Message Body
  5. 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 ذکر کردیم.

  1. General-Header
  2. Request-Header
  3. Response-Header
  4. 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></body>
</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،
GEThttps://www.tsmandegar.com/latest?type
به طور کلی شناسایی منبع رایج ترین و اصلی ترین وظیفه ای است که یک Request-URI داردبرای مثال، اگر یک کاربر بخواهد یک منبعی از اطلاعات را به طور مستقیم از سرور مبدا بازیابی کند، باید یک ارتباط TCP با پورت 80 هاست مورد نظرش مثلا www.itpro.ir بسازد، و کدی که در پایین آمده را به آن ارسال کند.
GET/latest?type=videos
Host: www.tsmandegar.com

نکته ای که حائز اهمیت است این است که Absolut Path یا همان مسیر یا آدرس کامل نباید خالی باشد، اگر آدرس جاری و کنونی در URL اصلی خالی است و هیچ مقداری ندارد، حد اقل باید با یک علامت “/” پر شود که بتواند آدرس را از ریشه یا همان Root بخواند.

Request Header Fields

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

  1. Accept-Charset
  2. Accept-Encoding
  3. Accept-Language
  4. Authorization
  5. Expect
  6. From
  7. Host
  8. If-Match
  9. If-Modified-Since
  10. If-None-Match
  11. If-Range
  12. If-Unmodified-Since
  13. Max-Forward
  14. Proxy-Authorization
  15. Range
  16. Refer
  17. TE
  18. 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 قرار می دهد.
 .
 .
منبع: itpro.ir

آشنایی با پروتکل HTTP – بخش اول

آشنایی با پروتکل HTTP – بخش اول

قبل از شروع این مجموعه آموزشی، خوبه که یک سری اطلاعات پایه در زمینه های ، مفاهیم وب، مرورگرهای اینترنت، وب سرورها، و همچنین نرم افزار های سمت سرور و کاربر داشته باشیم.
مطالب این مقاله بر اساس خصوصیات RFC-2616 می باشد که به پروتکل HTTP/1.1 اشاره دارد.
تفاوت عمده بین HTTP 1.0 و HTTP1.1 در این است که HTTP1.0 برای هر یک از پروسه های درخواست و پاسخ (Request/Response) یک ارتباط جدید ایجاد می کند، در صورتی که در HTTP1.1 برای مبادلات یک یا چندین درخواست و پاسخ از یک ارتباط استفاده می کند و ارتیاط جدیدی ایجاد نمی کند.

 

آخرین لایه از بین هفت لایه OSI لایه Application Layer می باشد، نکته ای که در مورد این لایه وجود دارد این است که این لایه بر خلاف اسمی که دارد هیچ گونه ارتباطی با نرم افزار های کاربردی ندارد، و تنها یک تشابه اسمی می باشد. در واقع این لایه محیطی را ایجاد میکند که نرم افزرا های کاربردی بتوانند با استفاده از آن با شبکه ارتباط برقرار کنند.
HTTP در این لایه مستقر است و از آن استفاده می کند، به طور کلی ، وظیفه و کاربرد HTTP توزیع و اشتراک اطلاعاتی ک به صورت ابر رسانه هستند می باشد.
ابر رسانه در واقع ، گسترش یافته ی ابر متن می باشد. یکسری اطلاعات معمولی غیر خطی شامل تصاویر، صدا، ویدئو ، متن ساده و ابر لینک ها می باشد.
HTTP پایه و اساسی برای ارتباط با صفحه ی جهان گستر(World Wide Web) می باشد.

 

HTTP یک پروتکل کاملا عمومی و مستقل است و شما می توانید از آن برای اهداف و مقاصد بسیار زیادی به غیر از وب نیز استفاده کنید ، علاوه بر این شما ازextension ها یا متعلقات این پروتکل مثل Request Method ها ( روش های درخواست) ، کدهای خطا یا Error Code ها و همچنین Header ها یا سرآیند هایی که در بسته های اطلاعاتی این پروتکل وجود دارد نیز می توانید استفاده کنید . برای مثال شما می توانید از طریق HTTP Header یک وب سایت، به نوع تکنولوژی مورد استفاده در آن پی ببرید.
مبنا و معماری پروتکل HTTP همچون پروتکل TCP/IP می باشد.HTTP سرویسی است که داده هایی همچون صفحات HTML ، تصاویر ، کوئری ها و… را برا روی صفحه ی جهان گستر (World Wide Web ) سرویس دهی می کند.
HTTP توانایی استفاده از پورت های مختلف را دارا می باشد، با این حال، پورت پیش فرضی که از آن استفاده می کند، پورت 80 می باشد. یک راه استاندارد برای ارتباط کامپیوتر ها با یکدیگر استفاده از پورت HTTP می باشد.
ویژگی خاصی که HTTP دارد این است که، پس از دریافت درخواست از سمت Client بررسی می کند که چگونه این درخواست را قالب بندی وبه سمت Serverارسال کند، و همچنین نحوه ی پاسخ Server به در خواست Client را نیز مشخص می کند.

ویژگی های عمومی
سه ویژگی که باعث شده HTTP در عین سادگی قدرتمند باشد عبارت است از:
بدون اتصال بودن(Connectionless)
مستقل بودن(Independent)
بدون وضعیت بودن(Stateless)

بدون اتصال بودن(Connectionless)
Client به وسیله ی مرورگر یک سرویس HTTP درخواست می کند ، Client به server وصل نیست، پس، منتظر پاسخ می ماند. Server درخواست Client را میبیند و پردازش می کند و برای ارسال پاسخ، دوباره یک ارتباط جدید با Client برقرار می کند.
مستقل بودن(Independent)
HTTP یک رسانه ی مستقل است، HTTP بر اساس نوع داده ای محتویات ارسالی توسط Client و همچنین نوع داده ای محتویاتی که Server به Client پاسخ میدهد، یک MIME مناسب درخواست میدهد، این بدان معناست که HTTP میتواند هر نوع داده ای که توسط Client و Server درخواست می شود، بدون هیچ مشکلی فراهم کند و محدود به داده های خاصی نمی باشد، پس کاملا مستقل است.
بدون وضعیت بودن(Stateless)
همان طور ک گفتیم HTTP بدون اتصال می باشد. Server و کاربر Client هر کدام تنها زمانی که آن دو با هم در ارتباط و تعامل هستند از یکدیگر با خبرند. بعد از آن هر دو آن ها، هر چیزی که بینشان بوده فراموش می کنند. با توجه به ماهیت این نوع پروتکل، نه Client و نه مرورگر نمی توانند اطلاعات بین درخواست های یک صفحه ی وب را نگه داری کنند.به همین دلیل است که میگوییم HTTP بدون وضعیت می باشد.

ساختار کلی

شکل زیر نموداری از ساختار کلی یک برنامه تحت وب و جایگاه HTTP در آن را به تصویر کشیده است:

پروتکل HTTP یک پروتکل درخواست و پاسخ می باشد که تحت معماری Client / Server ، بر روی مرورگرهای وب، ربات ها و موتور های جستجو و ..، پیاده سازی شده است، Clients عملیات های مر بوط به سمت کاربر و Web Servers عملیات مربوط به سمت سرور را در سرویس HTTP بر عهده دارند.

کاربر(Client)
در سرویس HTTP Client از طریق یک متد یا روش درخواست، درخواستی را به Server ارسال می کند، آدرس و نسخه ی پروتکل(Ipv6/Ipv4) و همچنین اصلاح محتویات پیام درخواستی ، اطلاعات کاربر و صحت بدنه و محتویات، به وسیله ی MIME بررسی می شود،
سرور(Server)
پاسخ های سرور در سرویس HTTP ، با یک خط وضعیت که شامل ورژن پروتکل پیام(Ipv6/Ipv4) موفقیت یا عدم موفقیت ارسال پیام که با یکسری کدهای خطا مشخص می شود، اطلاعات خاص مانند اطلاعات سرور و محتویات مجاز در داخل بدنه ی پیام تشریح می شود که همه ی این ها به وسیله ی استاندارد MIMEبررسی می شود.
در ادامه می خواهیم چند تا از مهم ترین پارامتر های HTTP و ساختار دستوری و راه های استفاده از آن ها مانند فرمت داده ها، فرمت آدرس ها و … را در هر ارتباط بیان کنیم. این اطلاعات به شما این امکان را می دهد که بتوانید، با ساختار و روش درخواست و پاسخ، پیام ها و اطلاعاتی که به وسیله ی HTTP ارسال و دریافت می کنید، بیشتر آشنا شوید. همچنین با برنامه ها و پروسه هایی که در روند ارسال و درخواست نقش دارند نیز بیشتر آشنا می شوید.
ورژن HTTP Version) HTTP)
HTTP از یک فرمول عددی برای نشان دادن ورژن پروتکل خود استفاده می کند، این روند یا فرمول بدین شکل می باشد که عدد بزرگتر یا Major با یک “.” از یک عدد کوچک تر یا Minor جدا می شود. ورژن پیام و اطلاعات HTTP با فیلدی تحت عنوان HTTP-Version در همان ابتدای ارسال مشخص می شود. ساختار کلی ورژن عددی HTTP به شکل زیر می باشد.

HTTP-Version=   “HTTP” “/” 1*DIGIT “.” 1*DIGIT

به عنوان مثال
HTTP/1.0
یا
HTTP/1.1

معرفی منابع یکسان(Uniform Resource Identifiers)
URI) Uniform Resource Identifiers) ، ساختار و فرمت بسیار ساده ای دارد، به طور مثال، حساس به متن نیست بدین معنا که نسبت به حروف کوچک و بزرگ حساس نیست و فرقی نمی کند که آدرس وب سایت یا وب سرویس شما با حروف کوچک ثبت شده باشد یا حروف بزرگ ، به مضمون و محتوای رشته ای که وارد می کنیم حساس نیست و… .
ازدیگر خصوصیات URI ، شناسایی و پیدا کردن یک منبع می باشد. مانند وب سرویس ها و وب سایت ها و … .
یک ساختار کلی از URI در اینجا ذکر شده:

URI = “http:” “//” host [ “:” port ] [ abs_path [ “?” query ]]

در این ساختار، اگر به جای Port مقداری تعریف نشده باشد و یا یک مقدار ناشناخته تعریف شده باشد، URI به صورت پیش فرض مقدار 80 را قرار می دهد. همچنین اگر به جای abs_path یک مقدار خالی و یا ناشناخته تعریف شده باشد، URI به صورت پیش فرض کاراکتر “//” را جایگزین می کند. سایر کاراکتر هایی که در ساختار بالا وجود دارند ، اگر مقداری خالی یا ناشناخته در آن ها قرا گرفته شده باشد، URI به صورت پیش فرض مقادیر % و Hex جایگزین می کند. در اینجا مثال هایی از حالت هایی که ذکر شد بیان شده است.

فرمت های تاریخ و زمان(Data/Time Formats)
تمامی نشانه های تاریخ و زمان در HTTP باید بر اساس تاریخ و ساعت گرینویچ نمایش داده شود (GMT) . برنامه و Application های HTTP تنها مجاز هستند که از این سه فرمت و ساختاری که در اینجا ذکر شده استفاده کنند.

Sun, 06 Nov 1994 08:49:37 GMT
Sunday, 06-Nov-94 08:49:37 GMT
Sun Nov 6 08:49:37 1994

مجموعه ی کاراکترها(Character Sets)
کاراکتر هایی که کاربر انتخاب می کند، ممکن است که نامشخص و ناخوانا باشد، HTTP آن ها را به صورت مجموعه ای از کاراکتر ها نمایش می دهد. بدین شکل که چندین کاراکتر که به هم چسبیده و پشت سر هم می آیند، با استفاده از کاما از یکدیگر جدا می کند. در اینجا مثالی از این حالت آورده ایم:

US-ASCII
ISO-8859-1
ISO-8859-7

رمزگذاری های محتوا(Content Encoding)
قبل از اینکه محتویات و داده ها به روی شبکه فرستاده شوند، HTTP ابتدا آن ها را رمز گذاری کرده و سپس به روی شبکه ارسال می کند. برای از بین نرفتن و حفظ هویت محتوای ارسالی ، باید حتما محتویات و داداه های ارسالی رمزگذاری شوند.HTTP داده ها را به صورت فشرده شده رمز گذاری می کند.
تمامی مقادیر محتویاتی که به صورت رمز شده درآمده اند، به صورت case- insensitive می باشد. ینی حساس به حروف نیستند.
در بخش های بعدی، استفاده از محتویات کد شده، و همچنین رمز گذاری فایل های سرآیند را توضیح خواهیم داد.
در زیر ساختار های معتبری از رمزگذاری محتویات نمایش داده شده است.

Accept-encoding: gzip
Accept-encoding: compress
Accept-encoding: deflate

انواع رسانه (Media Types)
HTTP انواع رسانه های اینترنتی، همچون تصاویر، صدا، ویدئو، و متن را درون محتوای خود بدون هیچ محدودیتی می پذیرد، مقادیر تمامی رسانه های مختلفی کهHTTP از آن ها استفاده می کند به صورت یک کد مشخص در IANA ثبت شده است. ساختار کلی رسانه های مختلف (Media Type) به شکل زیر می باشد.

media-type     = type “/” subtype *( “;” parameter )

در این ساختار Type ، SubType و Parameter همگی از نوع Case-Insensitive هستند.
مثال

Accept: image/gif

علائم زبان ها (Language Tags)
HTTP از علائم زبان ها برای نشان دادن زبان محتوا و همچنین بیان زبان قابل پذیرش توسط Application استفاده می کند.
یک علامت زبان (Language Tag) از یک یا چندین بخش تشکیل شده است .ساختار کلی یک علامت بدین ترتیب می باشد که یک علامت از زبان اصلی مانند (en) ، و همچنین یک سری علامت ک از علامت اصلی مشتق شده اند مثل (en-US) تشکیل شده اند، که علائم مشتق شده میتوانند وجود داشته باشند یا اصلا وجود نداشته باشند.

language-tag  = primary-tag *( “-” subtag )

مابین علامت ها نباید فضای خالی وجود داشته باشد، و همچنین همه ی علامت ها Case-Insensitive هستند.
مثال

en, en-US, en-cockney, i-cherokee, x-pig-latin

در این بخش ما با ساختار کلی HTTP و بعضی مفاهیم اصلی آشنا شدیم و همچنین با مبحاث HTTP Version ، URI ، Data/Time Format ، Character Sets ، Content Encoding ، Media Type و Language Tags آشنا شدیم.
در بخش های بعدی با مفهوم HTTP Messages و اجزای آن آشنا خواهیم شد.

.

.

منبع: itpro.ir