تعتمد شبكة الإنترنت في عملها علي مجموعة من بروتوكولات قياسية تستخدمها الحواسيب لتبادل البيانات . ولم يكن ممكنا لشبكة الإنترنت أو لأي شبكة أخري أن تنشأ من دون هذه البروتوكولات، وعلي الرغم من أن بروتوكول TCP/IP يعتبر البروتوكول الأساسي لشبكة الإنترنت إلا أن عمليات التحكم بكل وظيفة من الوظائف تتم عادة عن طريق بروتوكولات تتوضع فوق بروتوكول TCP/IP، وعندما تكون الأمور سائرة علي ما يرام، فإننا لا نشعر عادة بهذه البروتوكولات، إلا أنها تظهر أمامنا باستمرار، عند تركيب أدوات Tools جديدة، أو تنفيذ وظائف معينة، ويعتمد البريد الالكتروني علي البروتوكولات البسيط لنقل البريد SMTP، وعلي بروتوكول مركز البريد POP وتعمل قارئات الأخبار News Readers عن طريق بروتوكول نقل الاخبار عبر الشبكة NNTP، ويعتمد جلب الملفات عادة علي بروتوكول نقل الملفات FTP، ويكمن جزء من سحر شبكة الويب العالمية WWW (World Wide We في أنها بيئة متعددة البروتوكولات وهذا ما يمكننا من الوصول الي لوائح خدمة Ghoper ومواقع FTP وخدمات الإنترنت الأخرى، من خلال متصفحات شبكة ويب Web Browser ...
وعلي الرغم من أن شبكة الويب تسمح بالعديد من البروتوكولات، إلا أنها تحتوي علي بروتوكول أساسي يسمي "بروتوكول نقل النص المتشعب" HTTP (HyperText Transfer Protocol) . ويتحكم بروتوكول HTTP بعمليات استيردات الوثائق علي شبكة الويب Web التي تقوم بها برامج المتصفحات Browser، كما يتحكم بالتفاعلات التي تتم عبر شبكة ويب، من خلال مزايا معينة، مثل الاستمارات Forms، ولقد تم اعتماد الاصدارة رقم 1.1 المعتمد كمواصفات قياسية من قبل فريق عمل هندسة الانترنت IETF (Internet Engeneering Task Force) بعد أن تبنتها معظم المتصحفات الحديثة .
ينطلق بروتوكول 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 علي المزود، لاتمام عملية مرحلة الربط ( ما عدا في الحالات التي يشير فيها URL إلى بوابة أخرى ) .أما عن مرحلة الفصل أو الإغلاق فتتم في نهاية تبادلات 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 التي تعني غير شرعي . و تشير الشيفرات الاخرى إلى عدم السماح بطريقة طلب معينة 405، و إلى عدم توفر الخدمة 503، و إلى عدم دعم الوسط 415 الخ .. وتعتبر شيفرة الوضعية في الواقع استجابة مباشرة لمعالجة معلومات الطلب، ولكن أكثر شيفرات الوضعية انتشارا هي غير مرئية، هي 200 تعني OK ، إلا أن المتصفح لا يعرضها بل يعرض عوضا عنها الملف المطلوب الذي قام بجلبها ، وفيما يلي شيفرة استجابة بسيطة
أولا الصيغة
.. المحتويات الاخري للملف
[Connection cloes by foruign host]
كما هو الحال في رسالة الطلب، فإن رسالة الاستجابة يمكنها أن تحتوي علي حقول ترويسات، وتبلغ هذه الحقول برمجيات الزبون، بالطرق المسموحة، وتزودنا بمعلومات عن محتويات الرسالة ( مثل لغة المحتويات، و طول المحتويات، و نوع المحتويات )، و تعطي تفاصيل عن تواريخ التعديلات الخ ... و تساعد هذه الترويسة المتصفح بتفسير الملف أو المورد بشكل صحيح، بحيث يتمكن المتصفح من عرضها بشكل صحيح ...
المزيد من HTTP :
يضاف بشكل دائم المزيد من الخيارات إلى بروتوكول HTTP، لتغطية تبادلات مثل نصوص CGI, والشؤون الأمنية، فيضيف Secure-HTTP مثلا آليا تسمح بالتوقيع الرقمي و المزايا الأمنية الأخرى ( لمزيد من المعلومات انظر في الموقع http://www.commerce.net.8000/cgi-bin/texit?/information/standards/drafts/shttp.txt )
و ستستمر عمليات الإضافة على بروتوكول HTTP الأساسي لازدياد الحاجة الي تبادلات أكثر تعقيدا، و من المفيد أن نلقي نظرة علي موقع W3 Organization Web http://www.w3.org/ لمعرفة آخر التطورات في هذا المجال
و إلى وثيقة RFC رقم 2616 الخاص ببرتوكول HTTP...
http://rfc.net/rfc2616.html
وعلي الرغم من أن شبكة الويب تسمح بالعديد من البروتوكولات، إلا أنها تحتوي علي بروتوكول أساسي يسمي "بروتوكول نقل النص المتشعب" HTTP (HyperText Transfer Protocol) . ويتحكم بروتوكول HTTP بعمليات استيردات الوثائق علي شبكة الويب Web التي تقوم بها برامج المتصفحات Browser، كما يتحكم بالتفاعلات التي تتم عبر شبكة ويب، من خلال مزايا معينة، مثل الاستمارات Forms، ولقد تم اعتماد الاصدارة رقم 1.1 المعتمد كمواصفات قياسية من قبل فريق عمل هندسة الانترنت IETF (Internet Engeneering Task Force) بعد أن تبنتها معظم المتصحفات الحديثة .
ينطلق بروتوكول 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 علي المزود، لاتمام عملية مرحلة الربط ( ما عدا في الحالات التي يشير فيها URL إلى بوابة أخرى ) .أما عن مرحلة الفصل أو الإغلاق فتتم في نهاية تبادلات 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 والتفصيلات الأخرى و فيما يلي توضيح بسيط :
كود:
REQUEST SYNTAX الصيغة
"HTTP/1.1"
{:}*
EXMAPLE المثال
GET /index.htm HTTP/1.1
Accept: text/plain
Accept: text/plain
Accept: */*
User-Agent: Browserيزداد استخدام طريقة 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 التي تعني غير شرعي . و تشير الشيفرات الاخرى إلى عدم السماح بطريقة طلب معينة 405، و إلى عدم توفر الخدمة 503، و إلى عدم دعم الوسط 415 الخ .. وتعتبر شيفرة الوضعية في الواقع استجابة مباشرة لمعالجة معلومات الطلب، ولكن أكثر شيفرات الوضعية انتشارا هي غير مرئية، هي 200 تعني OK ، إلا أن المتصفح لا يعرضها بل يعرض عوضا عنها الملف المطلوب الذي قام بجلبها ، وفيما يلي شيفرة استجابة بسيطة
أولا الصيغة
كود:
RESONSE SYNTAX
"HTTP/1.0" []
{:*
EXAMLE المثال
HTTP/1.1 200 OK
Server:MDMA/0.1
MIME-Version:1.0
Content-type: text/html
Last-modified:Thu Jul 7 00:25:33 1999
Content-Length:2003
..[Connection cloes by foruign host]
كما هو الحال في رسالة الطلب، فإن رسالة الاستجابة يمكنها أن تحتوي علي حقول ترويسات، وتبلغ هذه الحقول برمجيات الزبون، بالطرق المسموحة، وتزودنا بمعلومات عن محتويات الرسالة ( مثل لغة المحتويات، و طول المحتويات، و نوع المحتويات )، و تعطي تفاصيل عن تواريخ التعديلات الخ ... و تساعد هذه الترويسة المتصفح بتفسير الملف أو المورد بشكل صحيح، بحيث يتمكن المتصفح من عرضها بشكل صحيح ...
المزيد من HTTP :
يضاف بشكل دائم المزيد من الخيارات إلى بروتوكول HTTP، لتغطية تبادلات مثل نصوص CGI, والشؤون الأمنية، فيضيف Secure-HTTP مثلا آليا تسمح بالتوقيع الرقمي و المزايا الأمنية الأخرى ( لمزيد من المعلومات انظر في الموقع http://www.commerce.net.8000/cgi-bin/texit?/information/standards/drafts/shttp.txt )
و ستستمر عمليات الإضافة على بروتوكول HTTP الأساسي لازدياد الحاجة الي تبادلات أكثر تعقيدا، و من المفيد أن نلقي نظرة علي موقع W3 Organization Web http://www.w3.org/ لمعرفة آخر التطورات في هذا المجال
و إلى وثيقة RFC رقم 2616 الخاص ببرتوكول HTTP...
http://rfc.net/rfc2616.html
ليست هناك تعليقات:
إرسال تعليق