HTTP چیست؟ قصد داریم تا در این مقاله جامع شما را بیشتر با پروتکل 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 در عین سادگی قدرتمند باشد عبارت است از:
Client به وسیله ی مرورگر یک سرویس HTTP درخواست می کند ، Client به server وصل نیست، پس، منتظر پاسخ می ماند. Server درخواست Client را میبیند و پردازش می کند و برای ارسال پاسخ، دوباره یک ارتباط جدید با Client برقرار می کند.
HTTP یک رسانه ی مستقل است، HTTP بر اساس نوع داده ای محتویات ارسالی توسط Client و همچنین نوع داده ای محتویاتی که Server به Client پاسخ میدهد، یک MIME مناسب درخواست میدهد، این بدان معناست که HTTP میتواند هر نوع داده ای که توسط Client و Server درخواست می شود، بدون هیچ مشکلی فراهم کند و محدود به داده های خاصی نمی باشد، پس کاملا مستقل است.
همان طور ک گفتیم HTTP بدون اتصال می باشد. Server و کاربر Client هر کدام تنها زمانی که آن دو با هم در ارتباط و تعامل هستند از یکدیگر با خبرند. بعد از آن هر دو آن ها، هر چیزی که بینشان بوده فراموش می کنند. با توجه به ماهیت این نوع پروتکل، نه Client و نه مرورگر نمی توانند اطلاعات بین درخواست های یک صفحه ی وب را نگه داری کنند.به همین دلیل است که میگوییم HTTP بدون وضعیت می باشد.
شکل زیر نموداری از ساختار کلی یک برنامه تحت وب و جایگاه HTTP در آن را به تصویر کشیده است:
پروتکل HTTP یک پروتکل درخواست و پاسخ می باشد که تحت معماری Client / Server ، بر روی مرورگرهای وب، ربات ها و موتور های جستجو و ..، پیاده سازی شده است، Clients عملیات های مر بوط به سمت کاربر و Web Servers عملیات مربوط به سمت سرور را در سرویس HTTP بر عهده دارند.
در سرویس HTTP Client از طریق یک متد یا روش درخواست، درخواستی را به Server ارسال می کند، آدرس و نسخه ی پروتکل (Ipv6/Ipv4) و همچنین اصلاح محتویات پیام درخواستی ، اطلاعات کاربر و صحت بدنه و محتویات، به وسیله ی MIME بررسی می شود،
پاسخ های سرور در سرویس HTTP ، با یک خط وضعیت که شامل ورژن پروتکل پیام(Ipv6/Ipv4) موفقیت یا عدم موفقیت ارسال پیام که با یکسری کدهای خطا مشخص می شود، اطلاعات خاص مانند اطلاعات سرور و محتویات مجاز در داخل بدنه ی پیام تشریح می شود که همه ی این ها به وسیله ی استاندارد MIME بررسی می شود.
در ادامه می خواهیم چند تا از مهم ترین پارامتر های HTTP و ساختار دستوری و راه های استفاده از آن ها مانند فرمت داده ها، فرمت آدرس ها و ... را در هر ارتباط بیان کنیم. این اطلاعات به شما این امکان را می دهد که بتوانید، با ساختار و روش درخواست و پاسخ، پیام ها و اطلاعاتی که به وسیله ی HTTP ارسال و دریافت می کنید، بیشتر آشنا شوید. همچنین با برنامه ها و پروسه هایی که در روند ارسال و درخواست نقش دارند نیز بیشتر آشنا می شوید.
HTTP از یک فرمول عددی برای نشان دادن ورژن پروتکل خود استفاده می کند، این روند یا فرمول بدین شکل می باشد که عدد بزرگتر یا Major با یک "." از یک عدد کوچک تر یا Minor جدا می شود. ورژن پیام و اطلاعات HTTP با فیلدی تحت عنوان HTTP-Version در همان ابتدای ارسال مشخص می شود. ساختار کلی ورژن عددی HTTP به شکل زیر می باشد.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
به عنوان مثال
HTTP/1.0
یا
HTTP/1.1
URI) Uniform Resource Identifiers) ، ساختار و فرمت بسیار ساده ای دارد، به طور مثال، حساس به متن نیست بدین معنا که نسبت به حروف کوچک و بزرگ حساس نیست و فرقی نمی کند که آدرس وب سایت یا وب سرویس شما با حروف کوچک ثبت شده باشد یا حروف بزرگ ، به مضمون و محتوای رشته ای که وارد می کنیم حساس نیست و... .از دیگر خصوصیات URI ، شناسایی و پیدا کردن یک منبع می باشد. مانند وب سرویس ها و وب سایت ها و یک ساختار کلی از URI در اینجا ذکر شده:
URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
در این ساختار، اگر به جای Port مقداری تعریف نشده باشد و یا یک مقدار ناشناخته تعریف شده باشد، URI به صورت پیش فرض مقدار 80 را قرار می دهد. همچنین اگر به جای abs_path یک مقدار خالی و یا ناشناخته تعریف شده باشد، URI به صورت پیش فرض کاراکتر "///" را جایگزین می کند. سایر کاراکتر هایی که در ساختار بالا وجود دارند ، اگر مقداری خالی یا ناشناخته در آن ها قرا گرفته شده باشد، URI به صورت پیش فرض مقادیر % و Hex جایگزین می کند. در اینجا مثال هایی از حالت هایی که ذکر شد بیان شده است.
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
تمامی نشانه های تاریخ و زمان در 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
کاراکتر هایی که کاربر انتخاب می کند، ممکن است که نامشخص و ناخوانا باشد، HTTP آن ها را به صورت مجموعه ای از کاراکتر ها نمایش می دهد. بدین شکل که چندین کاراکتر که به هم چسبیده و پشت سر هم می آیند، با استفاده از کاما از یکدیگر جدا می کند. در اینجا مثالی از این حالت آورده ایم:
US-ASCII ISO-8859-1 ISO-8859-7
قبل از اینکه محتویات و داده ها به روی شبکه فرستاده شوند، HTTP ابتدا آن ها را رمز گذاری کرده و سپس به روی شبکه ارسال می کند. برای از بین نرفتن و حفظ هویت محتوای ارسالی ، باید حتما محتویات و داداه های ارسالی رمزگذاری شوند.HTTP داده ها را به صورت فشرده شده رمز گذاری می کند.
تمامی مقادیر محتویاتی که به صورت رمز شده درآمده اند، به صورت case- insensitive می باشد. ینی حساس به حروف نیستند. در بخش های بعدی، استفاده از محتویات کد شده، و همچنین رمز گذاری فایل های سرآیند را توضیح خواهیم داد. در زیر ساختار های معتبری از رمزگذاری محتویات نمایش داده شده است.
Accept-encoding: gzip Accept-encoding: compress Accept-encoding: deflate
HTTP انواع رسانه های اینترنتی، همچون تصاویر، صدا، ویدئو، و متن را درون محتوای خود بدون هیچ محدودیتی می پذیرد، مقادیر تمامی رسانه های مختلفی که HTTP از آن ها استفاده می کند به صورت یک کد مشخص در IANA ثبت شده است. ساختار کلی رسانه های مختلف (Media Type) به شکل زیر می باشد.
media-type = type "/" subtype *( ";" parameter )
در این ساختار Type ، SubType و Parameter همگی از نوع Case-Insensitive هستند.
مثال
Accept: image/gif
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 امروز قصد داریم ک در مورد HTTP message ها و HTTP Request ها صحبت کنیم.همان طور که قبلا هم گفته شد، منظور از Client ، یک مرورگری می باشد که بتواند ارتباطی با سرور، به منظور ارسال یک یا چند پیام برقرار کند و همچنین ذکر کردیم که در HTTP منظور از Server در واقع یک Web Server می باشد که بتواند درخواست هایی را که از سمت Client برای برقراری یک ارتباط ارسال می شود به ترتیب پاسخ دهی کند، و از طریق HTTP یک پیامی را تحت عنوان پیام پاسخ یا Response Message به سمت Client ارسال کند.
همان طور که گفته شد، Server از طریق برنامه ای تحت عنوان Web Server اقدام به پاسخ درخواست های Client می کند، دو نمونه از Web Server ها که میتوان گفت معروف تر هستند، عبارت اند از Apache Web Server و Interne 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 می باشد، استفاده می کند. این پیام که یک قالب کلی دارد، از بخش های زیر تشکیل شده است که هر کدام را به صورت جداگانه توضیح خواهیم داد.
ساختار کلی یک 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 پاسخ داده است.
اطلاعات مورد نیاز مربوط به سرویس های درخواست و پاسخ در HTTP و یا موضوعات ارسالی که در بدنه ی پیام موجود می باشد، از طریق فیلد های سرآیند یا همان Header Fields اراائه می شود. در اینجا چهار نوع از پیام های سرآیند را در HTTP ذکر کردیم.
همه ی فیلد های سرآیندی که در بالا ذکر شد، همگی دارای ساختار یکسانی می باشند، که در اینجا ساختار کلی آن را به نمایش گذاشتیم.
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
برای یک پیام 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 زمانی که مرورگر یه درخواستی را به سمت 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 با یک Method token آغاز می شود به دنبال آن Request-URI و ورژن پروتکل مورد استفاده قرار می گیرد و با CRLF به پایان میرسد.دقت کنید که المان های Request-Line با Space از هم جدا می شوند. در اینجا قالب کلی Request-Line را مشاهده می کنید.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
در ادامه میخواهیم در مورد هر کدام از بخش های Request-Line نیز توضیحات بیشتری رائه کنیم.
بر اساس اطلاعاتی که Request-URI به HTTP می دهد، Request Method نوع کاری(Method) که باید بر روی منابع مشخص انجام شود را مشخص می کند . نکته ای که قابل توجه می باشد، این است که متد هایی که Request method تعیین می کند ، به حروف بزرگ و کوچک حساس می باشد، علاوه بر این باید با حروف بزرگ نوشته شوند تا بتواند آن ها را شناسایی کند.در اینجا لیستی از متدهایی که Request Method از آنها پشتیبانی می کند را لیست کردیم.
متد GET برای بازیابی اطلاعات از سرور داده استفاده می شود، که برای این کار از URI کمک می گیرد. درخواست هایی که از متد GET استفاده می کنند، تنها کاری که باید انجام دهند، بازیابی داده ها می باشد بدین معنا که نباید هیچ گونه اثری بر روی داده ها بگذارد، و تنها کاری که میکند، بازیابی اظلاعات از سرور داده باید باشد.
همانند متد GET می باشد با این تفاوت که متد HEAD وضعیت خط (Line) و همچنین بخش سرآیند پیام را نیز انتقال می دهد.
از متد POST برای ارسال اطلاعات به Server استفاده می شود، اطلاعاتی همچون اطلاعات مربوط به مشتری، آپلود فایل و موارد دیگر. متد POST برای ازسال اطلاعات به Server از فرم های ورود اطلاعات HTML استفاده می کند.
این متد، تمام نمونه های فعلی از منابع هدف را با آپلود کردن محتویات جایگزین می کند.
این متد دقیقا برعکس PUT عمل می کند، تمام نمونه های فعلی از منابع هدف را با استفاده از URI پاک می کند.
این متد یک تونل با استفاده از URI به سمت Server شناسایی و ایجاد می کند.
این متد تعدادی گزینه های ارتباطی را برای منابع هدف توصیف می کند.
این متد باعث می شود که کاربر به صورت مرحله به مرحله هر گونه تغییراتی که در روند Request صورت می گیرد را ببیند.
URI مخفف شده ی Uniform Resource Identifier می باشد، بدین معنا که، مشخص کننده ی منابع یکنواخت و یکسان می باشد. در اصل زمانی که یک REQUEST_URI ارسال می شود ، این سرویس صحت و هویت منابعی که در حال ارسال می باشد را بررسی می کند و بر میگرداند.در اینجا نمونه ای از قالب یک URI را ذکر کردیم،
Request-URI = "*" | absoluteURI | abs_path | authority
از علامت ستاره زمانی استفاده می شود که درخواست HTTP ارسالی توسط Client به یک منبع خاص صدق نمی کند و این درخواست تنها توسط server خود HTTP ارسالی صدق کند و قابل شناسایی و خواندن باشد. استفاده از دستور * زمانی مجاز می شود که پیام های ارسالی توسط HTTP با منابع موجود هیچگونه همخوانی نداشته باشد. به عنوان مثال،
OPTIONS * HTTP/1.1
از این دستور زمانی استفاده می شود که به یک پروکسی ساخنه شده، درخواست HTTP داده می شود. حال پروکسی فراخوانی شده، یک درخواست یا سرویسی را به سمت یک کش معتبر(Valid cash) ارسال می کند و در نهایت هم یک پاسخ از طریق همان کش معتبر دریافت می کند. مثالی از absoluteURI،
GET https://tosinso.com/articles=videos
به طور کلی شناسایی منبع رایج ترین و اصلی ترین وظیفه ای است که یک Request-URI داردبرای مثال، اگر یک کاربر بخواهد یک منبعی از اطلاعات را به طور مستقیم از سرور مبدا بازیابی کند، باید یک ارتباط TCP با پورت 80 هاست مورد نظرش مثلا www.tosinso.com بسازد، و کدی که در پایین آمده را به آن ارسال کند.
GET/latest?type=videos
Host: www.tosinso.com
نکته ای که حائز اهمیت است این است که Absolut Path یا همان مسیر یا آدرس کامل نباید خالی باشد، اگر آدرس جاری و کنونی در URL اصلی خالی است و هیچ مقداری ندارد، حد اقل باید با یک علامت "/" پر شود که بتواند آدرس را از ریشه یا همان Root بخواند.
بعد از اینکه فیلد های سر آیند HTTP را به طور کامل یاد گرفتیم، در بخش های بعد به طور کامل در مورد کلیت و ماهیت سرآیند ها بحث می کنیم و به طور کامل بررسی خواهیم کرد. خب، حال میخواهیم بدانیم که فیلد های سرآیند درخواست شامل چه چیزهایی می باشد و با مفهموم آن آشنا شویم.
فیلدهای سرآیند درخواست یا همان Request Header Fields به کاربر یا همان منبع درخواست این اجازه را میدهد تا یکسری اطلاعات اضافی همچون اطلاعاتی در مورد خود درخواست، یا به طور مثال اطلاعاتی در مورد ارسال کننده درخواست، به سمت سرور با خود حمل کند. به نوعی میتوان گفت که این فیلد ها برای اصلاح درخواست ها به کار می روند. در اینجا لیستی از مهم ترین فیلد های سرآیند درخواست که کاربردی تر هستند را ذکر کردیم.
در پایان هم مثال هایی از Request Message ذکر کردیم.در مثال اول می خواهیم یک صفحه ی hello.htm را از وب سرور tosinso.com به صورت یک درخواست HTTP واکشی کنیم.
GET /hello.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tosinso.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.tosinso.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 قرار می دهد.مثال بعدی نشان می دهد که چگونه میتوانید شما XML را داخل وب سرور خود قرار دهید.
POST /cgi-bin/process.cgi HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tutorialspoint.com Content-Type: text/xml; charset=utf-8 Content-Length: length 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>
تا اینجا ما در مورد HTTP Message و HTTP Request صحبت کردیم.همان طور که می دانید، زمانی که یک درخواستی از طرف Client به سمت سرور ارسال می شود، سرور به محض دریافت ، باید به آن درخواست پاسخ دهد، حال این درخواست می تواند ، یک پیام تایید باشد یا یک ارور، نکته ای که مهم است این است که در هر صورت یک جواب از سمت سرور به Client ارسال می شود. من هم سعی کردم در این مجموعه ی آموزشی این ترتیب و روند را حفظ کنم، بدین معنا که جلسه ی قبل در مورد HTTP Request صحبت کردم و در این جلسه در مورد HTTP Response و همچنین HTTP Method صحبت خواهم کرد که بتوانم، پاسخی به Request جلسه ی پیش داده باشم!
بعد از دریافت و تفسیر یک پیام درخواست یا 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 شامل توضیحاتی می باشد که در ادامه به بررسی هر یک از آن میپردازیم.
این پیام به نوعی وضعیت کلی خط را به ما نشان می دهد، ساختار آن هم همان طور که در کد زیر پیداست، بدین شکل می باشد که شامل، ورژن پرتکل مورد استفاده در پیام و بدنبال آن یک کد وضعیت نمایش داده می شود که به صورت عددی می باشد و بدنبال آن نیز یک عبارت متنی که به نوعی توضیحاتی در مورد وضعیت خط دریافت می کند نمایش داده می شود. فقط به این نکته هم باید دقت داشت که هر کدام از این بخش ها باید با کاراکتر Space از هم جدا شوند.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
این فیلد، ورژن پروتکل HTTP می باشد که سرور از آن پشتیبانی می کند .در اینجا مثالی از HTTP-Version آوره شده است
HTTP-Version = HTTP/1.1
این المان، یک کد سه رقمی از نوع عدد صحیح می باشد، اولین رقم آن بیانگر کلاسی از پاسخ ارسالی توسط سرور می باشد، دو رقم آخر این کد، عمل خاصی را انجام نمی دهد. در اینجا برای رقم اول کد پنج نمونه از ارقامی که می پذیرد را ذکر می کنیم.
نکته ای که حائز اهمیت می باشد، این است که ، کد های وضعیت HTTP بسیار گسترده هستند ، با این حال برنامه ها و توسعه دهنده های HTTP الزاما نباید مفهوم همه ی کد های ثبت شده را بدانند. مبحث کد های وضعیت HTTP در بخش های بعدی به طور جداگانه بررسی خواهد شد.
فیلد های سرآیند پاسخ، این اجازه را به سرور می دهند، که یک سری اطلاعات اضافی که تنها جنبه ی توضیحی از Response ارسالی توسط Server را دارند،به همراه پیام ارسالی به سمت Client ارسال کند. مشخصه و ویژگی منحصر به فرد این اطلاعات اضافی این است که هیچ فضایی از خطوط ارسالی را اشغال نمی کنند.این فیلد های سرآیند،اطلاعاتی در مورد سرور و همچنین اظلاعاتی در مورد دسترسی های بیشتر به منابعی که توسط درخواست های URI شناسایی شده است ، به ما می دهند.
مثال زیر نحوه ی اضافه کردن یک صفحه ی 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 Methods خواهیم پرداخت.
همان طور که دربخش قبلی گفتیم، Request Method نوع کار یا (Method) که باید بر روی منابع مشخص انجام شود را مشخص می کند . نکته ای که در بحث Request Method باید به آن توجه داشت، این است که متد هایی که Request method تعیین می کند ، به حروف بزرگ و کوچک حساس می باشد، علاوه بر این باید با حروف بزرگ نوشته شوند تا بتواند آن ها را شناسایی کند.در اینجا توضیح مختصری از متدهایی که Request 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.itrpo.ir 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>
همانند متد GET می باشد با این تفاوت که متد HEAD وضعیت خط یا (Line) و همچنین بخش سرآیند پیام را نیز انتقال می دهد. در اینجا نحوه ی ایجاد فایل سرآیند برای صفحه ی hello.htm را آوردیم
HEAD /hello.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tosinso.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 برای ارسال اطلاعات به 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: www.tosinso.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>
این متد، تمام نمونه های فعلی از منابع هدف را با آپلود کردن محتویات جایگزین می کند. در اینجا مثالی ذکر شده که درخواست های دریافتی از سرور را به صفحه ی hello.htm تحویل میدهد تا بتواند آن ها را در پوشه ی root در سرور ذخیره کند.
PUT /hello.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tosinso.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>
این متد دقیقا برعکس 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>
این متد یک تونل با استفاده از URI به سمت Server شناسایی و ایجاد می کند. در مثال زیر درخواست هایی که سرور برای ارتباط با یک هاست میدهد، به طور مثال tosinso.com ، ذکر شده است.
CONNECT www.itrpo.ir 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)
این متد بیشتر برای Client مفید می باشد، تا بتواند به وسیله ی آن متد های HTTP و سایر option هایی که وب سرور از ان ها پشتیبانی می کند را شناسایی و دریافت کند، ممکن است که یک Client بخواهد فقط از یک یا چند متد خاص استفاده کند، یا اینکه از همه ی متد هایی که وب سرور از آن ها پشتیبانی می کند، استفاده کند، که برای اینکار کافیست که از یک علامت ستاره(*) استفاده کند، به مثال زیر توجه کنید:
OPTIONS * HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
در پاسخ سرور لیستی از تمامی متد هایی که توانایی پشتیبانی از آن ها را دارد برای ما نمایش می دهد.
این متد باعث می شود که کاربر به صورت مرحله به مرحله هر گونه تغییراتی که در روند Request صورت می گیرد را ببیند. در اینجا مثالی از نحوه ی انجام این عمل را ذکر کردیم.
TRACE / HTTP/1.1 Host: www.tosinso.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: 39 TRACE / HTTP/1.1 Host: www.tutorialspoint.com User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)