تويت
HTTP : البروتوكول الاساسي لشبكة ويب العالمية ..
تعتمد شبكة إنترنت في عملها علي بروتوكولات قياسية تستخدمها الحواسيب لتبادل البيانات . ولم يكن ممكنا لشبكة إنترنت أو لاي شبكة أخري ان تنشأ من دون هذه البروتوكولات، وعلي الرغم من أن بروتوكول TCP/IP يعتبر البروتوكول الاساسي لشبكة إنترنت إلا أن التحكم بكل وظيفة من الوظائف تتم عادة عن طريق بروتوكولات تتوضع فوق بروتوكول TCP/IP، ويعتمد البريد الالكتروني علي البروتوكولات البسيط لنقل البريد SMTP، وعلي بروتوكول مركز البريد POP وتعمل قارئات الاخبار News Readers عن طريق بروتوكول نقل الاخبار عبر الشبكة NNTP، ويعتمد جلب الملفات عادة علي بروتوكول نقل الملفات FTP، وعلي الرغم من أن شبكة الويب تسمح بالعديد من البروتوكولات، الا انها تحتوي علي بروتوكول اساسي يسمي HTTP (HyperText Transfer Protocol) . ويتحكم بروتوكول HTTP بعمليات استردات الوثائق علي شبكة الويب Web التي تقوم بها برامج المتصحفات Browser، كما يتحكم بالتفاعلات التي تتم عبر شبكة ويب، من خلال مزايا معينة، مثل الاستمارات Forms، ينطلق بروتوكول HTTP في عمله كلما نقرنا علي وصلة تشعبية Hyperlink يبدا "محدد مكان مورد المعلومات الموحد" URL (Uniform Resource Locator) فيها بالرموز Http://، او كلما كتبنا URL يبدا بهذه الرموز . وتوفر معظم المتصحفات الحديثة مثل Netscape Navigator و Microsoft Internet Explorer عليك عناء كتابة هذه الروموز عن طريق اضافتها آليا الي عناوي URL التي تطلبها ( باستثناء تلك التي تبدا عنواوينها بالرموز FTP او Ghoper ) . ويبدا بروتوكول HTTP فور تشغيله بتنفيذ سسلة من العمليات، رباعية الاجزاء، ومؤلفة من المراحل التالية : مرحلة الربط (Connection)، مرحلة الطلب (request)، ومرحلة الاستجابة (Response)، ومرحلة الفصل (Disconnection)، أو الاغلاق (Cloes). وقد توسعت مزايا بروتوكول HTTP منذ ظهورها الاول عام 1991 الا ان هذه المراحل الاربع لا تزال تشكل جوهر عملها. وتمكن معظم المتصحفات الحديثة من متابعة هذه المراحل اثناء تنفيذها عنن طريق مراقبة شريط الحالة (Status Bar) .
لأن بروتوكول HTTP يعتبر من البروتوكولات التي تعتمد علي مبدا الطلب والاستجابة فهو يتطلب وجود مزود server وزبون Client ، لانهاء عملية التبادل . وساهمت شبكة الويب في انتشار مفهوم المزود بحيث نشات بين معظم مستخدمي انترنت وبرمجيات مزود الويب . ويمكن تعريف المزودات علي انها حواسيب تحتغظ بالمعلومات لتزود بها الزبون clinet الذي يطلبها . ويعتبر مصطلح الزبون Clinet اقل انتشارا علي شبكة الويب لان مفهوم المتصفح Browser قد حل محله . وتعتبر متصفحات الويب زبائن بروتوكول HTTP، تتالف من البرمجيات التي ترسل الطلبات وتستقبل الاستجابات، ويمكن ان ننظر الي تبادلات بروتوكول HTTP علي انها رسالة آسكي ASCII مرسلة من قبل الزبون واستجابة لتلك الرسالة من قبل المزود، ويمكن الفارق بين رسالة الطلب والاستجابة في مضمون الرسالة بحد ذاته .
مرحلة الرط ومرحلة الفصل :
سوف نعرض الي مرحلتين : الاولي والاخيرة، من تبادلات HTTP بشكل سريع نظرا لانها اقل المراحل الاربع تشويقا، ففي مرحلة الربط Connection يسعي ( المتصفح) الي اقامة علاقة ربط مع المزود ( الحاسوب البعيد )، وينظر الي اسم النطاق (Domain Name ) او الي رقم بروتوكول انترنت (IP Number ) الموجود ضمن مستطيل "محدد مكان مورد المعلومات الموحد" URL سعيا للاتصال مع المزود، ويحاول بروتوكول HTTP ان يستخدم البوابة Port رقم 80 علي المزود، لاتمام عملية مرحلة الربط . اما عن مرحلة الفصل او الاغلاق فتتم في نهاية تبادلات HTTP ، وتبدا هذه العملية بايعاز من الزبون، فور الانتهاء من نقل الملف المعني، أو بايعاز من الزبون اذا نفذ المزود المستخد امر الوقوف Stop، أو اذا نفذ تبادلا جديدا من نوع HTTP عن طريق الضغط علي نص تشعبي جديد، او اذا استخدم احد ازرار التراجع Back أو التقدم Forward في المتفصح، او اذا انتقي موضوعا جديدا من قائمة المواقع السابقة، في هذا المتصفح . ويتطلب كل واحد من الموضوعات التي تظهر علي صفحة الويب عملية ربط مستقلة لتبدا بنقل المعلومات. الا ان الاصدارة HTTP1.1 تتضمن نوعا من الربط المتواصل Persistent connection يسمي "البقاء حيا" Keep Alive يمكنه جلب ملفات متعددة ( مثل ملفات الرسومات) من خلال عملية ربط واحدة فقط .
مرحلة الطلب :
تبدا مرحلة الطلب فور انتهاء مرحلة الربط، ويقوم الزبون في هذه المرحلة بتقديم طلبه request الي المزود عن طريق ارسال رسالة اسكي باسطر وحقول معينة وتحتوي الرسالة في أعلاها ، علي سطر الطلب request line متبوعا بثلاثة سطور للترويسات : الترويسة العامة Genereal Header وترويسة الطلب Request Header وترويسة الكائن Entity Header، ويقصد بالكائن المعلومات او الملفات التي ترغب في ارسالها من متصفحك الي الحاسوب المزود، ويجد علي السطر التالي الترويسة الاخيرة حقل يسمي جسم الكائن او Entity Body ، وسنلقي فيما يلي نظرة علي كل سطر وحقل ..
يضم سطر الطلب Request Line في رسالة بروتوكول HTTP عددا من التفصيلات، بما فيها الطريقة المتعبة Method، ومعرف مكان مورد المعلومات الموحد URI (Uniform Resource Identifier ) واصدارة البروتوكول. ونلقي قبل الحديث عن الطريقة المتعبة، نظرة سريعة علي التفصيلات الاخري . يتالف معرف مكان مورد المعلومات الموحد URI عادة اما من "محدد مكان مورد المعلومات الموحد" URL او من " اسم مكان مورد المعلومات الوحد" URN (Uniform Resource Name )، وتكمن مهمته في الاشارة الي ملف او مورد اخري، من موارد الشبكة، اما اصدارة البروتوكول فهي كما يتضح من اسمها، تحدد بروتوكول HTTP المطلوب . ويحتوي الطلب بعد هذه المواصفات علي نوع من الرسائل، يتضمن مختلف المعدلات Modifiesrs والتفصيلات الاخري ..
يتضمن سطر الطلب في بروتوكول HTTP تحديد الطريقة المتبعة، اكثر الطرق انتشارا هي طريقة Get و طريقة Head وطريقة Post. وفيما تتضمن الطرق الاخري طريقة Put وطريقة Delete، وتتالف طريقة Get الاكثر انتشارا علي الاطلاق من تعليمة تطلب من المزود ارسال وثيقة او كائن الي الزبون . وحيث استخدام طلب Get فان متصحف الويب يقول "ارسل لي الملف الموجود عند عنوان URL المعن، بحيث استطيع عرض محتوياته علي المستخدم"، ويمكن تعديل طريقة Get باستخدام عبارات شرطية لطلب الملفات التي لها تاريخ معين، او عدلت بتاريخ معين، او تقع ضمن فئة ما، اما المحتويات نفسها فهي محددة في حقل Entity Body من الطلب، ويتمثل اختلاف طريقة Get عن طريقة Head فيما يلي: يرسل المزود في طريقة Head كل شيء الي الزبون باستثناء حقل Entity Body ، او بشكل ابسط فهو يرسل معلومات عن الملف وليس الملف ذاته، ويمكن استخدام طريقة Head لتحديد فيما اذا كان الربط المتشعب شرعيا ام لا، ونشير هنا الي ان برنامج تتبع تحديث العلامات المرجعية Bookmarks، تعتبر مثالا علي البرامج التي تستخدم طلبات Head ..
يزداد استخدام طريقة Post باطراد علي شبكة الويب، واذا سبق لك ان أنشات استمارات HTML Forms، فانك تعرف حكما طريقة Post، لان هذه الطريقة تحدد ماذا يحدث للمعلومات المسلمة عبر الاستمارات. وتطلب طريقة Post بشكل اساسي من المزود ان يقبل المعلومات المرفقة، كمعلومات مضافة معرفة URI معين، وتستخدم طريقة Post، علي سبيل المثال، لوضع رسالة او تعليق ضمن مساحات علي المزود تخصصها بعض مواقع الويب لهذا الغرض، ولاضافة معلومات لقواعد البيانات، ولارسال البيانات من استمارة ويب الي المزود. اما ما يحدث لتلك البيانات فيعتمد علي المزود ذاته، حيث يمكن ان ترسل الي قاعدة بيانات من خلال نص CGI Commom Getway Interface، أو يمكن ان تضاف علي هيئة محددة بشكل مسبق الي وثيقة HTML، ليتمكن الأخرون من مشاهدتها، الا ان هذا الامر لا يدخل في نطاق تبادلات بروتوكول HTTP.
تعتبر طريقة Put مشابهة لطريقة Post، فهي تطلب من المزود تخزين المعلومات المرفقة كملف ( كمورد) مسمي من قبل معرف URI في الطلب، واذا كان هذا الملف غير منشا، ينشئ المزود ملفا جديدا، اما اذا كان الملف منشأ، فيكتب عليه من جديد . ويكمن الفارق الرئيسي بين طريقة Post وطريقة Put في أن معرف URI في طريقة Post يقوم بتسمية المورد الذي سوف يهتم بالبيانات الموجودة في رسالة HTTP. اما ما يحدث لها بعد ذلك فيحدده المزود، وقد يؤدي هذا الامر، في الواقع الي تعديل مورد مختلف كليا، عن المورد الذي يحدده معرف URI ، اما في طريقة Put فإن معرف URI علي عكس ما ذكرنا، يشير الي المعلومات المرفقة، وليس علي مورد علي المزود، ولا يمكن للمزود ان يفعل شيئا بالمعلومات سوي تخزينها .
تعتبر طريقة Put اسهل هاتين الطريقتين، . تستخدم طريقة Delete للسبب ذاته، بشكل قليل نسبيا باستثناء استخدامات المشرفين علي المزودات. وتطلب طريقة Delete من المزود ان يتخلص من المورد المحدد في سطر معرف URI، لكن من غير المفضل ان تسمح بانجاز هذا العمل الخطر عم طريق بضع نقرات علي الوصلات المتشعبة، ولهذا السبب يتم اعداد المزودات بحيث تسمح باستخدام طرق معينة فقط .
قد تحتوي اسطر ترويسة الطلب Request Line من رسالة بروتوكول HTTP علي عدة حقول مختلفة مختلفة. وتحدد ترويسة Accept نوع الوسط، مثل ملفات الفيديو والصوت الذي يمكن ان يحتويه الاستجابة، علي حين أن حقل Accept-Encoding يحدد ان مجموعة الرموز المقبولة أو تقنيات الترميز المقبولة للاستجابة . وتغطي ترويسة التفويض Autorization header التفويضات المسموحة بين المتصفح والمزود . فيما تحتوي ترويسة Cashe-Control header علي زمرة معقدة من موجهات Directives الكاش.
ويتعامل بروتوكول HTTP1.1 بشكل مكثف مع التحكم بالكاش والذي اصبح مجالا هاما في تصميم وادارة شبكة الويب، خلال السنة الماضية . وتوجد ترويسات اخري تسمح لتحديد مواصفات الموقع ونوع المحتويات والتواريخ وتفصيلات تعديل المورد، وتفصيلات عن البروكسي وحتي معلومات حول المتصفح User-Agent الذي يقوم بالطلب . ومن المتوقع ان يزداد دور هذه الترويسات بشكل اكبر مع ازدياد تعقيدات شبكة الويب وزيادة تنوع التبادلات الداخلية، وتكامل مختلف الانواع الجديدة من الاوساط والمزايا ...
الاستجابة :
بعد ان ينتهي المتصفح من انشاء الربط مع المزود، وارسال طلبه ينتظر رسالة الاستجابة وتتالف رسالة الاستجابة كما هو الحال في رسالة الطلب من عدة سطور من المعلومات ويقع في بدايتها سطر الوضعية status line، متبوعا بمجموعة متنوعة من ترويسات الاستجابة ثم بالوثيقة او المورد المطلوب وتستغرق الاستجابة في معظم الاحيان، زمنا اطول لتنفيذها بالمقارنة مع زمن الطلب، وذلك بسبب احتوائها علي الملف او المورد المطلوب،، ويعتبر هذا الامر معكوسا في طلبات Post و Put ولكن معظم رسائل HTTP الآن هي طلبات Get بسيطة جدا...
يحتوي سطر الوضعية من الاستجابة علي رقم إصدارة HTTP، وشيفرة الوضعية وعبارة الاستجابة، وتتالف شيفيرات الوضعية status codes من مؤشرات ثلاثية الارقام تدل علي الطريقة التي تم فيها معالجة الطلب، لكن عبارة السبب Reason Phrase قصيرة، وتحتوي علي شرح للشيفرة Code، باللغة الانجليزية العادية. ويوجد خمسة تصنيفات لشيفرات الوضعية ...
1xx وتخصص لتفصايل المعلومات
2xx وتشير الي نجاح العملية
3xx وتعلمنا بانتهاء نقل معرف ال URI
4xx وتيشر الي خطأ من جانب المتصفح
5xx وتوضح أن المزود يعاني من مشاكل ...
ولا بد اننا شاهدنا بعضا من هذه الشيفرات مثل 403 التي تعني ممنوع الوصول، و401 التي تعني غير شرعي ....
، وفيما يلي شيفرة استجابة بسيطة
اولا الصيغة
RESONSE SYNTAX
"HTTP/1.0" <result-code>[<message>]<crlf>
{<Header>:<Value><crlf>*
<crlf>
كما هو الحال في رسالة الطلب، فان رسالة الاستجابة يمكنها ان تحتوي علي حقول ترويسات، وتبلغ هذه الحقول برمجيات الزبون، بالطرق المسموحة، وتزودنا بمعلومات عن محتويات الرسالة ( مثل لغة المحتويات، وطول المحتويات، ونوع المحتويات )، وتعطي تفاصيل عن تواريخ التعديلات الخ ...
:knight
تعتمد شبكة إنترنت في عملها علي بروتوكولات قياسية تستخدمها الحواسيب لتبادل البيانات . ولم يكن ممكنا لشبكة إنترنت أو لاي شبكة أخري ان تنشأ من دون هذه البروتوكولات، وعلي الرغم من أن بروتوكول TCP/IP يعتبر البروتوكول الاساسي لشبكة إنترنت إلا أن التحكم بكل وظيفة من الوظائف تتم عادة عن طريق بروتوكولات تتوضع فوق بروتوكول TCP/IP، ويعتمد البريد الالكتروني علي البروتوكولات البسيط لنقل البريد SMTP، وعلي بروتوكول مركز البريد POP وتعمل قارئات الاخبار News Readers عن طريق بروتوكول نقل الاخبار عبر الشبكة NNTP، ويعتمد جلب الملفات عادة علي بروتوكول نقل الملفات FTP، وعلي الرغم من أن شبكة الويب تسمح بالعديد من البروتوكولات، الا انها تحتوي علي بروتوكول اساسي يسمي HTTP (HyperText Transfer Protocol) . ويتحكم بروتوكول HTTP بعمليات استردات الوثائق علي شبكة الويب Web التي تقوم بها برامج المتصحفات Browser، كما يتحكم بالتفاعلات التي تتم عبر شبكة ويب، من خلال مزايا معينة، مثل الاستمارات Forms، ينطلق بروتوكول HTTP في عمله كلما نقرنا علي وصلة تشعبية Hyperlink يبدا "محدد مكان مورد المعلومات الموحد" URL (Uniform Resource Locator) فيها بالرموز Http://، او كلما كتبنا URL يبدا بهذه الرموز . وتوفر معظم المتصحفات الحديثة مثل Netscape Navigator و Microsoft Internet Explorer عليك عناء كتابة هذه الروموز عن طريق اضافتها آليا الي عناوي URL التي تطلبها ( باستثناء تلك التي تبدا عنواوينها بالرموز FTP او Ghoper ) . ويبدا بروتوكول HTTP فور تشغيله بتنفيذ سسلة من العمليات، رباعية الاجزاء، ومؤلفة من المراحل التالية : مرحلة الربط (Connection)، مرحلة الطلب (request)، ومرحلة الاستجابة (Response)، ومرحلة الفصل (Disconnection)، أو الاغلاق (Cloes). وقد توسعت مزايا بروتوكول HTTP منذ ظهورها الاول عام 1991 الا ان هذه المراحل الاربع لا تزال تشكل جوهر عملها. وتمكن معظم المتصحفات الحديثة من متابعة هذه المراحل اثناء تنفيذها عنن طريق مراقبة شريط الحالة (Status Bar) .
لأن بروتوكول HTTP يعتبر من البروتوكولات التي تعتمد علي مبدا الطلب والاستجابة فهو يتطلب وجود مزود server وزبون Client ، لانهاء عملية التبادل . وساهمت شبكة الويب في انتشار مفهوم المزود بحيث نشات بين معظم مستخدمي انترنت وبرمجيات مزود الويب . ويمكن تعريف المزودات علي انها حواسيب تحتغظ بالمعلومات لتزود بها الزبون clinet الذي يطلبها . ويعتبر مصطلح الزبون Clinet اقل انتشارا علي شبكة الويب لان مفهوم المتصفح Browser قد حل محله . وتعتبر متصفحات الويب زبائن بروتوكول HTTP، تتالف من البرمجيات التي ترسل الطلبات وتستقبل الاستجابات، ويمكن ان ننظر الي تبادلات بروتوكول HTTP علي انها رسالة آسكي ASCII مرسلة من قبل الزبون واستجابة لتلك الرسالة من قبل المزود، ويمكن الفارق بين رسالة الطلب والاستجابة في مضمون الرسالة بحد ذاته .
مرحلة الرط ومرحلة الفصل :
سوف نعرض الي مرحلتين : الاولي والاخيرة، من تبادلات HTTP بشكل سريع نظرا لانها اقل المراحل الاربع تشويقا، ففي مرحلة الربط Connection يسعي ( المتصفح) الي اقامة علاقة ربط مع المزود ( الحاسوب البعيد )، وينظر الي اسم النطاق (Domain Name ) او الي رقم بروتوكول انترنت (IP Number ) الموجود ضمن مستطيل "محدد مكان مورد المعلومات الموحد" URL سعيا للاتصال مع المزود، ويحاول بروتوكول HTTP ان يستخدم البوابة Port رقم 80 علي المزود، لاتمام عملية مرحلة الربط . اما عن مرحلة الفصل او الاغلاق فتتم في نهاية تبادلات HTTP ، وتبدا هذه العملية بايعاز من الزبون، فور الانتهاء من نقل الملف المعني، أو بايعاز من الزبون اذا نفذ المزود المستخد امر الوقوف Stop، أو اذا نفذ تبادلا جديدا من نوع HTTP عن طريق الضغط علي نص تشعبي جديد، او اذا استخدم احد ازرار التراجع Back أو التقدم Forward في المتفصح، او اذا انتقي موضوعا جديدا من قائمة المواقع السابقة، في هذا المتصفح . ويتطلب كل واحد من الموضوعات التي تظهر علي صفحة الويب عملية ربط مستقلة لتبدا بنقل المعلومات. الا ان الاصدارة HTTP1.1 تتضمن نوعا من الربط المتواصل Persistent connection يسمي "البقاء حيا" Keep Alive يمكنه جلب ملفات متعددة ( مثل ملفات الرسومات) من خلال عملية ربط واحدة فقط .
مرحلة الطلب :
تبدا مرحلة الطلب فور انتهاء مرحلة الربط، ويقوم الزبون في هذه المرحلة بتقديم طلبه request الي المزود عن طريق ارسال رسالة اسكي باسطر وحقول معينة وتحتوي الرسالة في أعلاها ، علي سطر الطلب request line متبوعا بثلاثة سطور للترويسات : الترويسة العامة Genereal Header وترويسة الطلب Request Header وترويسة الكائن Entity Header، ويقصد بالكائن المعلومات او الملفات التي ترغب في ارسالها من متصفحك الي الحاسوب المزود، ويجد علي السطر التالي الترويسة الاخيرة حقل يسمي جسم الكائن او Entity Body ، وسنلقي فيما يلي نظرة علي كل سطر وحقل ..
يضم سطر الطلب Request Line في رسالة بروتوكول HTTP عددا من التفصيلات، بما فيها الطريقة المتعبة Method، ومعرف مكان مورد المعلومات الموحد URI (Uniform Resource Identifier ) واصدارة البروتوكول. ونلقي قبل الحديث عن الطريقة المتعبة، نظرة سريعة علي التفصيلات الاخري . يتالف معرف مكان مورد المعلومات الموحد URI عادة اما من "محدد مكان مورد المعلومات الموحد" URL او من " اسم مكان مورد المعلومات الوحد" URN (Uniform Resource Name )، وتكمن مهمته في الاشارة الي ملف او مورد اخري، من موارد الشبكة، اما اصدارة البروتوكول فهي كما يتضح من اسمها، تحدد بروتوكول HTTP المطلوب . ويحتوي الطلب بعد هذه المواصفات علي نوع من الرسائل، يتضمن مختلف المعدلات Modifiesrs والتفصيلات الاخري ..
يتضمن سطر الطلب في بروتوكول HTTP تحديد الطريقة المتبعة، اكثر الطرق انتشارا هي طريقة Get و طريقة Head وطريقة Post. وفيما تتضمن الطرق الاخري طريقة Put وطريقة Delete، وتتالف طريقة Get الاكثر انتشارا علي الاطلاق من تعليمة تطلب من المزود ارسال وثيقة او كائن الي الزبون . وحيث استخدام طلب Get فان متصحف الويب يقول "ارسل لي الملف الموجود عند عنوان URL المعن، بحيث استطيع عرض محتوياته علي المستخدم"، ويمكن تعديل طريقة Get باستخدام عبارات شرطية لطلب الملفات التي لها تاريخ معين، او عدلت بتاريخ معين، او تقع ضمن فئة ما، اما المحتويات نفسها فهي محددة في حقل Entity Body من الطلب، ويتمثل اختلاف طريقة Get عن طريقة Head فيما يلي: يرسل المزود في طريقة Head كل شيء الي الزبون باستثناء حقل Entity Body ، او بشكل ابسط فهو يرسل معلومات عن الملف وليس الملف ذاته، ويمكن استخدام طريقة Head لتحديد فيما اذا كان الربط المتشعب شرعيا ام لا، ونشير هنا الي ان برنامج تتبع تحديث العلامات المرجعية Bookmarks، تعتبر مثالا علي البرامج التي تستخدم طلبات Head ..
يزداد استخدام طريقة Post باطراد علي شبكة الويب، واذا سبق لك ان أنشات استمارات HTML Forms، فانك تعرف حكما طريقة Post، لان هذه الطريقة تحدد ماذا يحدث للمعلومات المسلمة عبر الاستمارات. وتطلب طريقة Post بشكل اساسي من المزود ان يقبل المعلومات المرفقة، كمعلومات مضافة معرفة URI معين، وتستخدم طريقة Post، علي سبيل المثال، لوضع رسالة او تعليق ضمن مساحات علي المزود تخصصها بعض مواقع الويب لهذا الغرض، ولاضافة معلومات لقواعد البيانات، ولارسال البيانات من استمارة ويب الي المزود. اما ما يحدث لتلك البيانات فيعتمد علي المزود ذاته، حيث يمكن ان ترسل الي قاعدة بيانات من خلال نص CGI Commom Getway Interface، أو يمكن ان تضاف علي هيئة محددة بشكل مسبق الي وثيقة HTML، ليتمكن الأخرون من مشاهدتها، الا ان هذا الامر لا يدخل في نطاق تبادلات بروتوكول HTTP.
تعتبر طريقة Put مشابهة لطريقة Post، فهي تطلب من المزود تخزين المعلومات المرفقة كملف ( كمورد) مسمي من قبل معرف URI في الطلب، واذا كان هذا الملف غير منشا، ينشئ المزود ملفا جديدا، اما اذا كان الملف منشأ، فيكتب عليه من جديد . ويكمن الفارق الرئيسي بين طريقة Post وطريقة Put في أن معرف URI في طريقة Post يقوم بتسمية المورد الذي سوف يهتم بالبيانات الموجودة في رسالة HTTP. اما ما يحدث لها بعد ذلك فيحدده المزود، وقد يؤدي هذا الامر، في الواقع الي تعديل مورد مختلف كليا، عن المورد الذي يحدده معرف URI ، اما في طريقة Put فإن معرف URI علي عكس ما ذكرنا، يشير الي المعلومات المرفقة، وليس علي مورد علي المزود، ولا يمكن للمزود ان يفعل شيئا بالمعلومات سوي تخزينها .
تعتبر طريقة Put اسهل هاتين الطريقتين، . تستخدم طريقة Delete للسبب ذاته، بشكل قليل نسبيا باستثناء استخدامات المشرفين علي المزودات. وتطلب طريقة Delete من المزود ان يتخلص من المورد المحدد في سطر معرف URI، لكن من غير المفضل ان تسمح بانجاز هذا العمل الخطر عم طريق بضع نقرات علي الوصلات المتشعبة، ولهذا السبب يتم اعداد المزودات بحيث تسمح باستخدام طرق معينة فقط .
قد تحتوي اسطر ترويسة الطلب Request Line من رسالة بروتوكول HTTP علي عدة حقول مختلفة مختلفة. وتحدد ترويسة Accept نوع الوسط، مثل ملفات الفيديو والصوت الذي يمكن ان يحتويه الاستجابة، علي حين أن حقل Accept-Encoding يحدد ان مجموعة الرموز المقبولة أو تقنيات الترميز المقبولة للاستجابة . وتغطي ترويسة التفويض Autorization header التفويضات المسموحة بين المتصفح والمزود . فيما تحتوي ترويسة Cashe-Control header علي زمرة معقدة من موجهات Directives الكاش.
ويتعامل بروتوكول HTTP1.1 بشكل مكثف مع التحكم بالكاش والذي اصبح مجالا هاما في تصميم وادارة شبكة الويب، خلال السنة الماضية . وتوجد ترويسات اخري تسمح لتحديد مواصفات الموقع ونوع المحتويات والتواريخ وتفصيلات تعديل المورد، وتفصيلات عن البروكسي وحتي معلومات حول المتصفح User-Agent الذي يقوم بالطلب . ومن المتوقع ان يزداد دور هذه الترويسات بشكل اكبر مع ازدياد تعقيدات شبكة الويب وزيادة تنوع التبادلات الداخلية، وتكامل مختلف الانواع الجديدة من الاوساط والمزايا ...
الاستجابة :
بعد ان ينتهي المتصفح من انشاء الربط مع المزود، وارسال طلبه ينتظر رسالة الاستجابة وتتالف رسالة الاستجابة كما هو الحال في رسالة الطلب من عدة سطور من المعلومات ويقع في بدايتها سطر الوضعية status line، متبوعا بمجموعة متنوعة من ترويسات الاستجابة ثم بالوثيقة او المورد المطلوب وتستغرق الاستجابة في معظم الاحيان، زمنا اطول لتنفيذها بالمقارنة مع زمن الطلب، وذلك بسبب احتوائها علي الملف او المورد المطلوب،، ويعتبر هذا الامر معكوسا في طلبات Post و Put ولكن معظم رسائل HTTP الآن هي طلبات Get بسيطة جدا...
يحتوي سطر الوضعية من الاستجابة علي رقم إصدارة HTTP، وشيفرة الوضعية وعبارة الاستجابة، وتتالف شيفيرات الوضعية status codes من مؤشرات ثلاثية الارقام تدل علي الطريقة التي تم فيها معالجة الطلب، لكن عبارة السبب Reason Phrase قصيرة، وتحتوي علي شرح للشيفرة Code، باللغة الانجليزية العادية. ويوجد خمسة تصنيفات لشيفرات الوضعية ...
1xx وتخصص لتفصايل المعلومات
2xx وتشير الي نجاح العملية
3xx وتعلمنا بانتهاء نقل معرف ال URI
4xx وتيشر الي خطأ من جانب المتصفح
5xx وتوضح أن المزود يعاني من مشاكل ...
ولا بد اننا شاهدنا بعضا من هذه الشيفرات مثل 403 التي تعني ممنوع الوصول، و401 التي تعني غير شرعي ....
، وفيما يلي شيفرة استجابة بسيطة
اولا الصيغة
RESONSE SYNTAX
"HTTP/1.0" <result-code>[<message>]<crlf>
{<Header>:<Value><crlf>*
<crlf>
كما هو الحال في رسالة الطلب، فان رسالة الاستجابة يمكنها ان تحتوي علي حقول ترويسات، وتبلغ هذه الحقول برمجيات الزبون، بالطرق المسموحة، وتزودنا بمعلومات عن محتويات الرسالة ( مثل لغة المحتويات، وطول المحتويات، ونوع المحتويات )، وتعطي تفاصيل عن تواريخ التعديلات الخ ...
:knight
[/align]
تعليق