لمحه عن بروتوكول نقل النص الفائق

بروتوكول نقل النص الفائق هو البروتوكول الذي تقوم عليه الويب (الشبكه العالميه العنكبوتيه أو World Wide Web)  وهو البروتوكول المعني بتنظيم آليه العمل بين متصفح الويب وبين خادم الويب، وهو البروتوكول الذي يحدد كيف يطلب المتصفح صفحة ما من خادم الويب، ويحدد كيف يتعامل خادم الويب مع ذلك الطلب. يعمل هذا البروتوكول من خلال طبقه التطبيقات (Application Layer)، وهي الطبقه النهائيه في بروتوكول TCP/IP (الشكل كذا)

الشكل  4 طبقة التطبيقات ضمن حزمه بروتوكول الـ TCP/IP

إن بروتوكول نقل النص الفائق قائم على طلب من العميل ورد من الخادم. يطلق على هذه الطلبات والردود «رسائل». إن كل «رسالة» مرسلة من العميل أو الخادم تبنى وفق قواعد البروتوكول، وسوف أحاول أن أشرح بروتوكول نقل النص الفائق من خلال عرض رسائل البروتوكول باستخدام وسيط (Proxy) وهو أسلوب يسهم في فهم أعمق لطريقه عمل البروتوكول.

وسيط بروتوكل نقل النص الفائق

إن استخدام وسيط محلي (Local Proxy) يساعدك في عرض واعتراض الحزم الصادره من والوارده إلى متصفح الويب، بل و تعديلها أيضا إن أردت، وهذه الطريقه لاغنى عنها إذا كنت تريد فحص تطبيقات الويب وكيفيه عملها واختبار ردود أفعالها ضد الحالات والإحتمالات والمدخلات المختلفه.

هناك عدة برامج تقوم بهذه المهمه، وهذه بعضها: (تتمه: قم بعمل قائمه أكبر من خلال OWASP LiveCD)

• Paros Proxy

وهو برنامج سهل الإستخدام

• WebScarab

مثل Paros تمت كتابته بلغه جافا

• WebScarab-NG

الجيل الأحدث من WebScarab

• Firefox LiveHeaders

إضافه (Plugin) لمتصفح فايرفوكس يمكنك من خلالها متابعه حزم البروتوكول

وسوف أستخدم هنا برنامج Paros Proxy لننظر نظره مدققه أكثر إلى طريقه عمل البروتوكول.

بعد أن تقوم بتثبيت Paros، عليك أولا أن تقوم بالذهاب إلى إعدادات المتصفح الذي تود استخدامه، ومن ثم تقوم بتعديلها. كالتالي (سوف نقوم بالشرح على متصفح فايرفوكس، وبالطبع يمكنك اتباع نفس الخطوات مع تعديل بسيط في باقي المتصفحات):

1. من قائمه الأدوات (Tools)، اذهب إلى الاختيارات (Options)
2. ومن ثم اذهب إلى الإختيارات المتقدمه (Advanced) واختر التبويب (Tab) الخاص بالشبكه (Network)
3. انقر على زر الضبط (Settings)
4. ثم قم باختيار إعدادات الوسيط اليدويه (Manual proxy configurations)
5. قم بكتابة «localhost» و «8080» في خانه الوسيط (HTTP Proxy) والمنفذ (Port) على التوالي
6. ثم علم على الاختيار الخاص باستخدام الوسيط لكل البروتوكولات (Use this proxy for all protocols)
7. ثم انقر على زر موافق (OK)

إن المنفذ الذي قمنا باختياره هو نفس المنفذ الفطري الذي ينصت له برنامج Paros، وإذا كان المنفذ 8080 مستخدما عن طريق برنامج آخر، فيمكنك إعداد Paros ليستخدم منفذا آخر ^([1])، ومن ثم تقوم باعداد المتصفح ليستخدم ذلك المنفذ الجديد

1. والآن شغل برنامج Paros، ثم اذهب إلى Trap – أقصى تبويب على اليمين – ثم قم باختيار Trap request و Trap response

إن فكره Trap – أو الكمين، الفخ، المصيده – هو اعتراض الحزمه الصادره من المتصفح والوارده إليه قبل أن تصدر منه أو أن ترد إليه، وبالتالي فان الفخ يعطيك الوقت الكافي لفحص الحزمه وتعديلها إذا أردت

1. قم بتشغيل فايرفوكس، ثم اذهب إلى الموقع الذي تود فحصه، وليكن Google

يمكنك الآن فحص كل شيء يصدر من أو يرد إلى المتصفح …

تحت غطاء محرك السيارة (Under the hood)

ماذا يحدث بالضبط في جلسه تصفح موقع الويب؟  إن الإجابه عن هذا السؤال قد تكون ممتعه للكثيرين، خاصة المطورين الذين يقومون بتطوير تطبيقاتهم لتتعامل مع هذا البروتوكول^([2]).

للحصول على نتائج دقيقه، يفضل تجاهل كل البيانات التي قام المتصفح بتخزينها قبل ذلك، مثل الحلويات والصور وخلافه. ويمكنك بدلا من حذف كل تلك البيانات أن تبدأ جلسه تصفح خاص (Start Private Browsing)، وبالتالي سوف يتجاهل المتصفح كل البيانات التي تم تخزينها مسبقا

هذا المساء سوف نذهب إلى جوجل …

عندما تقوم بكتابة عنوان جوجل في خانة عنوان المتصفح، ثم تضغط زر الإدخال، سوف يتم إرسال واستقبال رسائل بين كل من المتصفح والخادم، وسوف يبدأ Paros في اعتراض الحزم.

الطلب (Request) رقم 1

 هاك أول رسالة قام بارسالها المتصفح^([3]):

السطر رقم	محتوى السطر
1	GET / HTTP/1.1
2	Host: www.google.com
3	User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
4	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5	Accept-Language: en-us,en;q=0.5
6	Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
7	Keep-Alive: 115
8	Connection: keep-alive
9

كما ترى، قام المتصفح – نيابة عنك – بارسال العديد من التعليمات الى خادم الويب الخاص بجوجل. وفقا لبروتوكول نقل النص الفائق.

قبل الدخول في تفاصيل الطلب السابق، علي أولا أن أوضح «هيكل» أو «بناء» (Structure) رسائل البروتوكول.

إن رسائل البروتوكول مقسمه إلى أقسام ثلاثه:

• رأس الرسالة

هو السطر الأول في الرسالة (السطر رقم واحد في الجدول السابق)

• توجيهات الرسالة

هي مجموعة من التوجيهات يتم إرسالها تساعد كلا من العميل والخادم في تنفيذ الطلب/الرد (من السطر الثاني وحتى السطر التاسع)

• جسم الرسالة

هو محتوى الرسالة (وهو اختياري، فلا يجب أن يحتوي كل طلب من العميل أو كل رد من الخادم على الجسم)

رأس الرسالة (السطر رقم 1)

1	GET / HTTP/1.1

 تبدأ الجلسه بان يحدد العميل – المتصفح – أحد «الوسائل» المتعارف عليها، مثل:

• «GET» وفيها يطلب العميل من خادم الويب إحضار صفحه أو مكون ما
• «POST» وفيها يقوم العميل بارسال بيانات إلى خادم الويب (غالبا عن طريق إستمارة ويب – Web Form)
• «HEAD» وفيها يطلب العميل من خادم الويب إرسال رأس الرساله دون محتواها (أي عرض معلومات خادم الويب عن الصفحه دون إرسال محتوى الصفحه نفسه)
• «OPTIONS» وفيها يطلب العميل من خادم الويب إخباره عن «الوسائل» المتاحه التي يدعمها (مثل GET، POST وغيرهما)

إن كل وسيله من الوسائل التي تم الإتفاق عليها في البروتوكول تستخدم وفق قواعد محدده، فإذا استلم خادم الويب طلبا من العميل – المتصفح – دون أن يكون هذا الطلب متوافقا مع قواعد البروتوكول، فان خادم الويب قد يقوم برفض هذا الطلب وعدم إتمامه. لذا فانه عندما يتم استخدام وسيله GET، يقوم العميل بتحديد «مسار» المكون الذي يريده مبدوءا بعلامة الجذر «/»، فاذا كان العميل يريد الصفحه الرئيسيه للموقع، فانه يستخدم علامة «/» ثم لاشيء بعدها، وإذا كان يريد الصفحه contactus.html مثلا فانه سوف يستخدم المسار «/contactus.html» واذا كان يريد الصورة logo.png الموجوده في مجلد الصور مثلا، فانه سوف يستخدم المسار «/images/logo.png»، وهكذا مع كل الصفح والمكونات التي يطلبها العميل.

بعد تحديد مسار المكون المطلوب، يتم إخبار خادم الويب برقم إصدار بروتوكول نقل النص الفائق الذي يطالب العميل باتباعه في الجلسه. وهنا قام المتصفح بطلب إتباع تعليمات الإصدار 1.1 من بروتوكول نقل النص الفائق.

مثل كل تقنيات الحاسب، هناك عدة إصدارات من هذا البروتوكول، وكما هو متوقع، فان كل إصدار لاحق يعالج بعض العيوب ويضيف بعض الإمكانيات عن الإصدار السابق، وهكذا.

• الإصدار 0.9

تم نشر هذا الإصدار في عام 1991، وكان به العديد من العيوب التصميميه، ولم يكن يدعم سوى وسيله واحده فقط هي وسيله «GET»

• الإصدار 1.0

يعتبر هذا الإصدار هو أول إصدار من البروتوكول يتم نشره على نطاق واسع. أضاف هذا الإصدار العديد من الإمكانيات المتاحه حاليا، مثل إستمارات الويب، الوسائط، توجيهات البروتوكول (HTTP Headers) وغيرها، وقد ساهم هذا الإصدار بشكل فعال في نشر خدمه الويب حول العالم

• الإصدار 1.1

هو الإصدار الحالي للبروتوكول. وقد ركز هذا الإصدار على إصلاح العيوب في الإصدار السابق واهتم بتحسين سرعه الأداء، ودعم إمكانيات جديده، مثل دعم تعدد المواقع على خادم واحد بسهوله ويسر (كما سنرى لاحقا)

• الإصدار 2.0 (أو HTTP-Next Generation (NG))

هو إصدار مقترح لاحق للإصدار الحالي، وقد تم الإنتهاء من عرض الأبحاث الخاصه بهذا الإصدار المقترح في عام 1998. ولا يوجد أي خطط لإحلال هذا الإصدار بدل الإصدار الحالي في الوقت الحالي

Host (السطر رقم 2)

2	Host: www.google.com

هنا يقوم العميل بتحديد اسم الموقع ورقم المنفذ الذي يريد التعامل معه. و سوف يفترض الخادم أن المنفذ المطلوب هو المنفذ رقم «80» – المنفذ الفطري لخادم الويب – إذا لم يحتوي هذا التوجيه على رقم منفذ ما. إن هذا التوجيه يساعد الخادم في تحديد الموقع المطلوب إذا كان الخادم يستضيف أكثر من موقع على نفس عنوان الإنترنت، وهو ما يسمى بـ «الإستضافه المشتركه».

الإستضافه المشتركه – وأحيانا تسمى الإستضافه الظاهريه (Virtual Hosting) – هي تشارك أكثر من موقع واحد في مصادر جهاز واحد، وبالتالي يشترك أكثر من موقع واحد في نفس عنوان الإنترنت الخاص بذلك الجهاز، بعكس «الإستضافه المخصصه» – Dedicated Hosting – والتي يقوم فيها جهاز واحد بخدمه موقع واحد. وفي حاله الإستضافه المخصصه فان عمليه توجيه العميل للموقع المطلوب سهله، فان كل جهاز من تلك الأجهزه مخصص له عنوان إنترنت خاص به.

لم يكن بروتوكول نقل النص الفائق الإصدار رقم 1.0 يعطي أيه وسائل لخادم الويب لتعينه في تحديد الموقع الإفتراضي الذي يريد العميل الوصول إليه في حاله كون خادم الويب يستضيف أكثر من موقع، لذا كان على مدير النظام أن يعتمد على حلول خارج بروتوكول نقل النص الفائق لحل هذه المشكله:

• وضع معرف خاص في عنوان الموقع أو الصفحه المطلوبه بحيث يتم تحديد العميل إلى الموقع المطلوب بناء على هذا المعرف. على سبيل المثال، عندما يطلب عميل ما الموقع http://somesite.com/ahmed/index.html يتم تحويله حسب المعرف الخاص «ahmed» – الموجود في عنوان الصفحه – إلى المجلد الخاص بالعميل «/var/www/htdocs/ahmed/» وهكذا.
• تحديد منفذ مخصص لكل موقع. على سبيل المثال يعطى الموقع http://somesite.com/ المنفذ رقم «81»، ويعطى الموقع http://someothersite.com/ المنفذ رقم «82» وهكذا. طبعا سوف يضطر العميل إلى كتابه رقم المنفذ الغير تقليدي في خانه عنوان المتصفح وإلا لن يصل للموقع المطلوب
• تحديد عنوان إنترنت مختلف لكل موقع. على سبيل المثال، يعطى الموقع http://somesite.com/ عنوان الإنترنت رقم 1.2.3.4 بينما يعطى الموقع http://someothersite.com/ العنوان 5.6.7.8، وبالتالي يستطيع خادم الويب تحديد الموقع الذي يريده العميل بالنظر إلى عنوان الإنترنت المطلوب عندما يقوم متصفح العميل بفتح قناة اتصال TCP إلى هذا العنوان. طبعا سوف يقوم مدير النظام بربط كل عناوين الإنترنت الخاصه بالمواقع الذي يستضيفها بخادم الويب.
• إجراء تحسينات للإصدار رقم 1.0 بحيث يحتوي على توجيه جديد «Header» يقوم بحل تلك المشكله. وقد ظهرت تحسينات بهذا المضمون قبل الإصدار 1.1

إن الحلول الثلاثه الأولى يعتريها بعض المشاكل، فتغيير العنوان أو المنفذ هو حل غير مرضي حيث يتسبب في تغيير عنوان الموقع أو يضطر العميل إلى كتابه منفذ محدد في خانه العنوان وهو حل غير مريح. والحل الثالث له مشاكله الخاصه، فان أرقام عناوين الإنترنت في اتجهاها إلى النضوب – اتكلم هنا عن عناوين الإنترنت الإصدار 4 (IPv4) وليس الإصدار 6 (IPv6) – وبالتالي فان هذا الحل سوف يسرع من وتيرة نضوب العناوين، وهو وإن كان أفضل الحلول الثلاثه، إلا أنه يخلق مشاكله الخاصه على المدى الطويل.

لكل هذه الأسباب تمت إضافه ذلك التوجيه في الإصدار رقم 1.1، وبالتالي أصبح هناك حلا سهلا لذلك العيب التصميمي في الإصدار السابق والذي افترض أن كل خادم ويب سوف يستضيف موقعا واحدا فقط.

إن هذا التوجيه يعد ضروريا في الإصدار رقم 1.1، فاذا استلم خادم الويب طلبا محددا بهذا الإصدار دون احتواءه على التوجيه «Host» فان على الخادم أن يرد بالكود رقم «400» – طلب غير صحيح (Bad Request) – ومن ثم يمتنع عن إتمام طلب العميل.

User-Agent (السطر رقم 3)

3	User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

عن طريق «User-Agent» يقوم العميل بارسال معرف خاص لتميزه عن باقي المتصفحات المختلفه. إن هذا التوجيه لا تحكمه قواعد كتلك التي تحكم توجيهات أخرى. فهذا التوجيه يختلف – بطبيعه الحال – بين متصفح وآخر، وبين إصدارين مختلفين لنفس المتصفح.

اسم ورقم الإصدار الخاص بالمتصفح	توجيه «User-Agent»
«Internet Explorer 9.0»	Mozilla/5.0 (Windows; MSIE 9.0; Windows NT 9.0; en-US)
«Google Chrome 12.0.742.100» نسخة اللينوكس	Mozilla/5.0 ArchLinux (X11; U; Linux x86_64; en-US) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30
«Google Chrome 12.0.742.100» نسخة النوافذ	Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30
«Firefox 4» نسخة اللينوكس	Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:2.0) Gecko/20110404 Fedora/16-dev Firefox/4.0
«Firefox 4» نسخة النوافذ	Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20110319 Firefox/4.0
الجدول كذا-كذا بعض توجيهات «User-Agent» لمتصفحات مختلفه

هذا التوجيه يساعد في تحديد الصفحات المناسبه حسب نظام تشغيل العميل، فعندما يعلن المتصفح عن نفسه  أنه نسخه خاصه بـ «Linux» – كما في الجدول السابق – قد يتم توجيه العميل إلى برامج معده سلفا لنظام التشغيل المناسب. على سبيل المثال، عندما تود تحميل نسخه من برنامج «Adobe Reader» سوف يتم تحويلك إلى صفحه التحميل المناسبه لنظام التشغيل الموجود في توجيه «User-Agent»^([4]).

بطبيعه الحال هذا التوجيه من الممكن أن يتم تعديله من قبل العميل، فمن الممكن أن يتم تعديل المعرف الخاص بالمتصفح ليصبح – مثلا – «Coc@-Col@» أو «me@somewebsite.com» أو أي شيء آخر.

Accept (السطر رقم 4)

4	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

عن طريق التوجيه «Accept» يقدم العميل قائمه بانواع الوسائط الذي سوف يقبلها من خادم الويب. يتم تحديد نوع الوسائط وفق معايير مسبقه، هذه المعايير تسمى بـ «إمتداد بريد الإنترنت متعدد الإستخدام» أو «MIME» – Multipurpose Internet Mail Extensions – وقد تم إنشاء تلك المعايير لدعم رسائل البريد الإلكتروني:

• دعم الحروف خارج نطاق «ASCII»
• دعم الملحقات غير النصيه (كالصور وخلافه)

وقد تم استخدام «MIME» لوصف وتحديد محتوى الوسائط عموما دون التقيد بالبريد الإلكتروني. وتقوم منظمه «Internet Assigned Number Authority» – وهي المنظمه القائمه بتحديد عناوين الإنترنت وفقا للتقسيم الجغرافي – بتسجيل وتحديد محتوى الوسائط وفقا لتصنيفات رئيسيه تحتها تصنيفات فرعيه، وهناك بعض الوسائط الشائعه لم تسجل بعد في قائمة المنظمه السابقه أو مازالت قيد التجربه، لذا يرمز لتلك الوسائط بالحرف «x».

على سبيل المثال، فان التنصيف الرئيسي «text» تحته التصينفات الفرعيه «css,html,javascript,plain,rtf,xml» وغيرها. والتصنيف «image» تحته التصنيفات الفرعيه «png,jpg,gif,bmp» وغيرها.

وكما سنرى لاحقا، فان على الخادم أن يقوم بتحديد نوع المحتوى الذي سوف يرسله إلى العميل، فاذا كان سوف يرسل له صفحه «html» كان عليه أن يقوم باعلامه مسبقا قبل إرسالها، وكذا في الصور والفلاش وباقي أنواع الوسائط.

 في الجدول التالي سوف نستعرض بعد أنواع الـ «MIME» الشائعه.

نوع الـ «MIME»	الوصف	الإمتداد المعروف للمحتوى
text/html	ملف من نوع html	.html .htm
text/plain	ملف نص بسيط (كملف ناتج عن استخدام محرر بسيط مثل «Notepad»)	.txt
text/javascript	ملف يحتوي على نصوص لغة «JavaScript»	.js
image/gif	صوره من نوع «GIF»	.gif
image/jpeg	صوره من نوع «JPEG»	.jpeg .jpg
text/css	ملف يحتوى على لغة «Cascading Style Sheets»	.css
application/pdf	ملف من نوع «PDF»	.pdf
application/zip	أرشيف من نوع «ZIP»	.zip
application/x-shockwave-flash	ملف من نوع «FLASH»	.swf
الجدول كذا – كذا بعض أنواع الوسائط الشائعه

ومن الممكن أن يقوم المتصفح باستخدام العلامه «*» لتحديد كل المحتويات المتاحه. على سبيل المثال:

• text/*

المتصفح يقبل كل التصنيفات الفرعيه تحت التصنيف الرئيسي «text»، أي أن المتصفح يقبل كل ما هو مدرج تحت تصنيف النصوص

• image/*

المتصفح يقبل كل التصنيفات الفرعيه تحت التصنيف الرئيسي «image»، أي أن المتصفح يقبل كل أنواع الصور المتاحه

• */*

المتصفح يقبل أي محتوى على الإطلاق

يحدد الخادم أولويه المحتوى المطلوب من اليمين إلى اليسار، فالمحتوى الذي على أقصى اليمين له الأولويه القصوى، والذي على أقصى اليسار له الأولويه الدنيا.

من الممكن أيضا أن يحدد العميل «جودة» المحتوى المطلوب عن طريق المتغير «q». أقل قيمه للمتغير هي «0.0» وأكبر قيمه هي «1.0» التي هي أيضا القيمه الفطريه – إذا لم يقم العميل باستعمال المتغير «q» أصلا، فان الخادم سوف يفترض أن قيمه «q» هي «1.0». كلما إتجهت القيمه للأعلى كان ذلك دليلا على تفضيل العميل للمحتوى المحدد. على سبيل المثال، في الطلب السابق، حدد التوجيه «Accept» القيمه التاليه:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

إن هذا معناه أن العميل يفضل إستلام محتوى من نوع «text/html, application/xhtml+xml,application/xml» بنسبه «0.9» بينما يفضل إرسال باقي أنواع المحتويات بنسبه أقل «0.8»، وبالتالي يحدد الخادم المحتوى المفضل لدى العميل.

Accept-Language (السطر رقم 5)

5	Accept-Language: en-us,en;q=0.5

«Accept-Language»  يحدد العميل اللغة التي يدعمها ويفترض أن خادم الويب سوف يرسل إليه المحتوى وفق اللغة التي يدعمها العميل، بشرط أن يكون الخادم لديه أكثر من نسخه للمحتوى المطلوب، بحيث أن كل نسخه من تلك النسخ تم إعدادها بلغة مختلفه عن النسخ الأخرى، فان الخادم سوف يرسل للعميل النسخه المتوافقه مع اللغه التي تم تحديدها في التوجيه «Accept-Language».

طبعا ككل توجيهات البروتوكول، فان المطور قد يحدد في تطبيق ما كيفيه تعامله مع تلك التوجيهات. على سبيل المثال، يمكن للمطور أن يقوم بتطوير تطبيق ما بحيث يحدد لغه المحتوى المطلوب وفق التوجيه «Accept-Language». فاذا أرسل العميل في هذا التوجيه ما مفاده أن العميل يفضل اللغه العربيه، فان التطبيق سوف يرسل له نسخه عربيه من المحتوى المطلوب، وهكذا.

اللغة	كود اللغه
العربيه	ar
الصينيه	zh
الألمانيه	nl
الإنجليزيه	en
الفرنسيه	fr
الجدول كذا – كذا بعض اللغات المختلفه وأكوادها

Accept-Charset

 (السطر رقم 6)

6	Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

توجيه «Accept-Charset» يحدد مجموعة الحروف (Character Set) التي يدعمها العميل، وبالتالي سوف يرسل الخادم نسخه من محتوى الصفحه باستخدام مجموعة الحروف تلك.

ظهرت الحاجه لإيجاد بديل لمنظومه حروف «ASCII» التي وضعتها « المنظمه الأمريكيه لمعايير تبادل المعلومات» عندما بدأ الحاسب في الإنتشار عالميا، كانت مجموعة حروف «ASCII» كافيه تماما للعالم المتحدث باللغه الإنجليزيه، حيث أن السعه التخزينيه التي اعتمدتها المنظمه لتخزين كل حرف من مجموعة الحروف هي 7 «بت» ^([5])- وليس «بايت» – وبالتالي فإن عدد الحروف التي يمكن تخزينها ضمن مجموعة حروف «ASCII» هي 128 حرف. وقد كانت تلك الحروف كافيه للكثير جدا من الحروف، فالحروف التي تمثل اللغه الإنجليزيه هي 52 حرف – كل حرف من الحروف الـ 26 يتم تمثيله مرتان، مره كبير (Capital) ومره أخرى صغير (Small) – بالإضافه إلى حروف التحكم – كـ «ESC» و «DEL» (Escape و Delete على التوالي) وأيضا الأرقام والكثير من الرموز. إلا أن مجموعة الحروف تلك لا تستطيع تمثيل باقي حروف لغات العالم، مثل حروف اللغة العربيه واللغه الصينيه – التي تحتوي على عدد هائل من الحروف. لذا تم البحث عن حل مناسب لتلك المشكله.

لحل تلك المشكله ظهرت مجموعات حروف أخرى، كمجموعة «ISO-8859-6» ذات السعة التخزينيه 8 «بت» – أي أن كل حرف يتم تخزينه على «بايت» كامل – والتي تستطيع تمثيل حروف اللغة العربية بالإضافة إلى الحروف الإنجليزيه.

هناك أيضا مجموعة الحروف «UTF-8» و «UTF-16» و «UTF-32» التي تقوم بالتخزين على 8 و 16 و 32 «بت» على التوالي، والمجموعه الأخيره قادره على تخزين أكثر من 4 مليارات حرف (4,294,967,296 تحديدا)

Keep-Alive (السطر رقم 7)

7	Keep-Alive: 115

«Keep-Alive» خاصية تتيح إعادة استعمال وصلة الـ TCP التي تم إنشاءها لتحقيق الإتصال بين العميل والخادم، وبالتالي توفر عمليه إنشاء إتصال جديد كلما أراد العميل إحضار صفحه أو مكون جديد.

عندما يطلب المستخدم من متصفح الويب الذهاب إلى موقع ما، فان هذه العمليه تتم عبر عدة خطوات:

أ‌.         يستخلص المتصفح اسم الخادم من عنوان الموقع، على سبيل المثال إذا قام المستخدم بطلب الذهاب إلى العنوان www.somewebsite.com/somepage.htm فان المتصفح سوف يستخلص اسم الخادم فقط وهو www.somewebsite.com

ب‌.     يحول المتصفح اسم الخادم إلى عنوان إنترنت (IP) عن طريق «خادم اسم النطاق» – Domain Name Server (DNS)

ت‌.     يستخلص المتصفح رقم المنفذ الخاص بالخادم (إذا وجد) من العنوان المطلوب

ث‌.     يبدأ المتصفح بانشاء قناة اتصال TCP بينه وبين الخادم، يتم ذلك عن طريق إستخدام منفذ محلي مؤقت في جهاز العميل ومنفذ دائم لدى خادم الويب (عادة المنفذ رقم 80)

إن بروتوكول TCP/IP يحدد كيفيه فتح قناة اتصال بين العميل/الخادم كالتالي:

1. يرسل العميل حزمة معلمة بـ «SYN» إلى المنفذ الذي يريد الإتصال به على عنوان الإنترنت الخاص بالخادم
2. إذا كان المنفذ متاحا، يرسل الخادم حزمة معلمة بـ «SYN/ACK» للعميل
3. عندما يتسلم العميل تلك الحزمه، يرد عليها بارساله حزمه معلمه بـ «ACK»
4. عند هذه النقطه يتم إنشاء قناة اتصال بين العميل/الخادم ويتم تبادل المعلومات

ج‌.      يقوم المتصفح بارسال الطلب

ح‌.      يقوم الخادم بالرد على طلب المتصفح

خ‌.      تغلق قناة الإتصال ويعرض المتصفح المحتوى الذي تم إرساله

وبالتالي، إذا أراد المتصفح إحضار صفحه أو مكون آخر، عليه أن يقوم باعادة فتح قناة اتصال TCP جديده (الخطوة «ث»)، مما يؤدي إلى جهد زائد لدى كل من المتصفح وخادم الويب.

لهذا قدم الإصدار 1.1 من بروتوكول نقل النص الفائق إمكانيه إعادة استخدام قناة TCP المفتوحه بدلا من إنشاء قناة جديدة. وعندما لا يقدم العميل توجيه «Keep-Alive» فان الخادم سوف يفترض وجودها فطريا – طالما أن العميل قد قام بتقديم طلبه مستخدما الإصدار 1.1 – وبالتالي سوف يستخدم نفس قناة الإتصال لاحقا في إرسال واستقبال المعلومات من ذلك العميل، بعكس الإصدار 1.0 الذي لايدعم هذا التوجيه فطريا، إذ يتحتم على العميل استخدام التوجيه «Keep-Alive» ليخبر الخادم أنه يود إعادة استخدام قناة الإتصال.

إن قيمة التوجيه هو الوقت الذي يود فيه العميل ابقاء قناة الإتصال مفتوحه بالثواني، وفي المثال السابق كان الوقت المطلوب هو 115 ثانيه.

Connection (السطر رقم 8)

8	Connection: keep-alive

«Connection» هنا يقول العميل للخادم أنه يود استعمال خاصيه «Keep-Alive» وبالتالي توفير عبئ إنشاء إتصال TCP جديد كلما أراد العميل إحضار صفحه أو مكون جديد.

إذا كان العميل يود إستخدام تلك الخاصيه – الذي ترتبط كما ترى بالتوجيه السابق «Keep-Alive» – فان عليه أن يرسل مع كل طلب لاحق التوجيه «Connection» مستخدما القيمه «Keep-Alive» وإلا سوف يغلق الخادم قناة الإتصال المستعمله بعد إرسال الطلب، وسوف يضطر العميل إلى إنشاء قناة إتصال TCP جديده.

سطر خالي (السطر رقم 9)

إن وجود السطر الخالي معناه انتهاء رأس الرساله بكل ما يحتويه من توجيهات، وأن محتوى الرسالة – إن وجد – سوف يأتي بعد ذلك السطر الخالي. وكل رسالة يجب أن يكون لها رأس، ولكن لا يجب أن يكون لها محتوى (سوف يظهر الفارق بين رأس الرساله ومحتواها بطريقة أوضح في بعض الرسائل القادمه بين العميل والخادم)

الرد (Response) رقم 1

عندما يقوم الخادم باستقبال طلب العميل، يقوم بمعالجته ومن ثم يقوم بارسال الرد …

محتوى السطر	السطر رقم
HTTP/1.1 302 Found	1
Location: http://www.google.com.eg/	2
Cache-Control: private	3
Content-Type: text/html; charset=UTF-8	4
Set-Cookie: PREF=ID=bfca422cf9ffb15a:FF=0:TM=1308352530:LM=1308352530:S=C7rU6idAfo0AGQjW; expires=Sun, 16-Jun-2013 23:15:30 GMT; path=/; domain=.google.com	5
Date: Fri, 17 Jun 2011 23:15:30 GMT	6
Server: gws	7
Content-Length: 222	8
X-XSS-Protection: 1; mode=block	9
	10
<HTML><HEAD><meta http-equiv=”content-type” content=”text/html;charset=utf-8″> <TITLE>302 Moved</TITLE></HEAD><BODY> <H1>302 Moved</H1> The document has moved <A HREF=”http://www.google.com.eg/”>here</A>. </BODY></HTML>	11
الجدول كذا-كذا رد الخادم على طلب العميل

رأس الرسالة (السطر رقم 1)

HTTP/1.1 302 Found

1

عندما يقوم الخادم بالرد على طلب العميل، فانه يقوم بذلك وفقا لتعليمات البروتوكول. ووفق تلك التعليمات، فان السطر الأول – رأس الرسالة – يجب أن يحتوي على رقم الإصدار الخاص ببروتوكول نقل النص الفائق المتبع في الرد على طلب العميل، ثم كود الرد. كود الرد يبين ماذا حدث لطلب العميل وفق أكواد محدده سابقا، كل كود عباره عن 3 أرقام، الخانه الأولى – من على اليسار –  تحدد تصنيف الكود:

• من 100 إلى 199 إعلامي (Informational)
• من 200 إلى 299 ناجح (Successful)
• من 300 إلى 399 إعادة توجيه (Redirection)
• من 400 إلى 499 خطأ العميل (Client Error)
• من 500 إلى 599 خطأ الخادم (Server Error)

وهذا جدول ببعض الأكواد الشائعه:

كود الرد (Status Code)	الحاله (Status)
200 OK	ناجح (ما طلبه العميل تم إرساله في محتوى الرد)
302 Object Moved	إعادة توجيه (على العميل الإتجاه إلى الموقع (Location) المحدد لإحضار طلبه
304 Not Modified	إن العميل يستفسر من الخادم إذا كانت النسخه المخزنه لديه في «النقد» (Cache) مازالت ساريه، وهنا يرد الخادم أن النسخه المخزنه ساريه ومتوافقه تماما مع الصفحه الأصليه (صفحه الويب المستضافه لدى الخادم)
400 Bad Request	طلب خاطئ (لم يراعي العميل تعليمات البروتوكول)
401 Unauthorized	غير مصرح (ومن ثم على العميل تعريف نفسه – عادة باستخدام اسم المستخدم وكلمه السر – لتنفيذ طلبه)
404 Not found	غير موجود (ما طلبه العميل لم يتم العثور عليه)
500 Internal Server Error	خطأ خادم داخلي (واجه الخادم مشكله ما عندما كان يحاول تنفيذ الطلب. عادة نتيجه خطأ في تنفيذ تطبيق قام المطور بكتابته بطريقة ما وعندما حاول الخادم تنفيذ التعليمات الواردة في التطبيق واجهته مشكلة ما)
501 Not Implemented	لا يوجد دعم (على سبيل المثال، استخدم العميل «وسيله» لا يدعمها الخادم)
جدول كذا – كذا بعض أنواع كود الرد الشائعه

Location (السطر رقم 2)

Location: http://www.google.com.eg/

2

عندما يريد الخادم إعادة توجيه العميل إلى موقع آخر، يحدد الخادم الوجهه الجديده عن طريق توجيه «Location»، ومن ثم يقوم العميل بالذهاب إلى الوجهه الجديده للحصول على طلبه. وهنا طلب جوجل إعادة توجيهي إلى موقع http://www.google.com.eg/.

إن هذا التوجيه لا يتحتم وجوده في كل رد – تماما مثل الكثير من التوجيهات الأخرى – فغالبا يحصل العميل على طلبه دون حدوث إعادة توجيه. إلا أن الكثير من مواقع وتطبيقات الويب تقوم بإعادة توجيه العميل إلى صفحات/مواقع أخرى. فقد قام جوجل – في هذا المثال – بتحويل العميل إلى موقع جوجل مصر بعد أن لاحظ أن عنوان الإنترنت الخاص به ينتمي إلى مصر. أيضا فانه عندما يتم التحقق من هوية العميل – عن طريق اسم المستخدم أو كلمة السر مثلا – فانه غالبا ما يتم تحويله إلى صفحته الخاصه عن طريق التوجيه «Location»

Cache-Control (السطر رقم 3)

Cache-Control: private

3

هذا التوجيه يحدد كيفيه تعامل «النقد» (Cache) مع الرد. هنا يطلب الخادم عدم تخزين محتوى الرد ضمن «النقد المشترك» (Shared Cache) وأن محتوى الرساله هو محتوى «خاص» (Private). ومن الممكن أن يقوم «النقد الخاص» (Private Cache) بتخزين محتوى الرساله.

إن فكرة «النقد» قائمه على التوفير، توفير الإتصال بالسعة التخزينيه. فعندما يتشارك عدد ما من العملاء في خادم نقد مثلا، فمن الممكن خدمه أحد العملاء بمكون – صورة مثلا – تم تخزينه من طلب سابق لعميل ما، وبالتالي يتم توفير عبئ إحضار «نسخه طازجه» (Fresh Copy) من هذا المكون، ويتم خدمه العميل بنسخه تم حفظها سابقا من تلك الصوره، وبالتالي يتم توفير سعة تخزينيه للاحتفاظ بنسخ من تلك المكونات بدلا من طلبها مجددا كل مره عندما يطلبها هذا العميل أو ذاك. فكرة النقد يتم تطبيقها على نطاقين:

• مشترك (Shared)

على سبيل المثال، قد يقوم مقدم خدمة الإنترنت (Internet Service Provider) بتوفير خادم نقد مشترك لكل عملائه، وبالتالي عندما يقوم أحد العملاء بطلب صفحه أو مكون ما، يبحث الخادم عن نسخه مخزنه، فاذا وجدها يتأكد من أن تلك النسخه المخزنه لم تجاوز تاريخ صلاحيتها بعد، ومن ثم يقوم بارسالها للعميل. أما إذا كان تاريخ الصلاحيه قد انتهى أو لم يجد نسخه محفوظه من طلب العميل أساسا، فانه سوف يقوم باحضار نسخه – طازجه بطبيعة الحال – من تلك الصفحه أو المكون

• خاص (Private)

تقدم كل متصفحات الويب خدمه «النقد الخاص»، فهي تقوم بتخزين نسخ من الصفحات أو المكونات التي طلبها العميل في وقت سابق، تماما كالنقد المشترك، إلا أن النقد الخاص يكون في خدمه عميل واحد فقط

Content-Type (السطر رقم 4)

Content-Type: text/html; charset=UTF-8

4

هذا التوجيه يحدد نوع الوسائط ( الـ«MIME») الذي سوف يتم إرساله في جسم الرسالة. تذكر أن المتصفح قام بتحديد أنواع الوسائط أو المحتويات التي سوف يقبلها – أنواع الـ «MIME» – عن طريق التوجيه «Accept» الذي تم إرساله في الطلب رقم 1.

إن غالبيه مصادر الويب تتكون من أنواع مختلفه من المكونات، فهناك الصور والفلاش ونصوص وفقرات HTML و JavaScript وغيرها الكثير، وكل هذا المكونات – طالما أنها تقبع في في ملفات منفصله – لها معرف «MIME» خاص بها يحدد محتواها ويميز ذلك المحتوى عن باقي أنواع المحتويات الأخرى، لهذا كان على الخادم أن يرسل توجيه «Content-Type» ليحدد فيه نوع المحتوى المرسل، وبالتالي يتعامل المتصفح وفق هذه المعلومات المقدمه من الخادم في عرض مصدر الويب بطريقه صحيحه.

لنفترض أن الصفحه contactus.html هي كالتالي:

<html>

<head>

<title>Contact Us</title>

<link href=”/css/style.css” />

</head>

<body>

<img src=”/images/logo.png” />

Contact us at 1234567890

</body>

</html>

إن هذه الصفحه كما ترى عباره عن المكونات التاليه:

• نصوص وفقرات HTML
• نصوص CSS
• صوره من نوع PNG

بالتالي هناك أكثر من نوع من أنواع المحتويات المختلفه في هذه الصفحه. لهذا عندما يرسل الخادم الصفحه – ومكوناتها الخارجيه (كالصور ونصوص CSS) تباعا – عليه أن يرسل مع كل محتوى التوجيه الذي يحدد نوع هذا المحتوى. إن توجيهات «Content-Type» التي سوف يرسلها الخادم سوف تكون كالتالي:

التوجيه	نوع المحتوى
Content-Type: text/html	نصوص HTML
Content-Type: text/css	نصوص CSS
Content-Type: image/png	صورة من نوع PNG
الجدول كذا-كذا توجيه «Content-Type» يختلف باختلاف المحتوى الذي يتم إرساله

فعندما يرسل الخادم ذلك التوجيه مصحوبا بـ «text/html» يقوم المتصفح بتهيئه نفسه لاستقبال محتوى من نوع نصوص مكتوبه بلغة html وبالتالي يقوم بعرضها بنفسه. وعندما يرسل الخادم ذلك التوجيه مصحوبا بـ «application/pdf» فان المتصفح سوف يبحث في إمكانيه عرض هذا النوع من المحتوى – الذي لا يدعمه بنفسه ولكنه يحتاج إلى برنامج آخر لعرضه – وبالتالي فانه سوف يبحث في مكونات النظام عن برنامج يتيح التعامل مع هذا النوع من الوسائط/المحتويات، فاذا وجده – على سبيل المثال، كان المستخدم قد قام بتثبيت برنامج Adobe Reader– فانه سوف يستخدم مكونات ذلك البرنامج في عرض المحتوى، أما إذا لم يجد أي مكون في النظام يتعامل مع المحتوى المحدد، فسوف يترك وسيله عرض ذلك المحتوى للمستخدم لاحقا.

Set-Cookie (السطر رقم 5)

Set-Cookie: PREF=ID=bfca422cf9ffb15a:FF=0:TM=1308352530:LM=1308352530:S=C7rU6idAfo0AGQjW; expires=Sun, 16-Jun-2013 23:15:30 GMT; path=/; domain=.google.com

5

في هذا التوجيه يطلب الخادم من العميل أن يقوم بانشاء بعض «الكوكيز»^([6])

ما هي «الكوكيز»؟

إن بروتوكول نقل النص الفائق هو بروتوكول غير قادر على تذكر «الحالة» – (State) لذا يطلقون عليه «Stateless». بمعنى أنه يقوم بخدمة طلبات العملاء دون قدرة منه على إنشاء رابطه واضحه بينه وبين العميل. وبالتالي فانه لم تكن هناك وسيلة عملية – فيما سبق – لإنشاء تلك الرابطة أو المعرف الواضح الذي يميز كل عميل عن الآخر.

هذه المشكلة تم حلها باستخدام الحلويات. الحلويات هي معلومات يرسلها الخادم إلى العميل ومن ثم يقوم العميل بإعادة إرسالها للخادم في طلباته اللاحقة. يمكنك تخيل الحلويات على أنها «بطاقة» يقوم العميل بتثبيتها في كل طلباته اللاحقة، وبالتالي كل ما على الخادم فعله هو أن ينظر إلى تلك البطاقة وبالتالي يحدد كيفية التعامل مع هذا العميل أو ذاك.

 ويمكن تقسيم الكوكيز – عامة – إلى نوعين:

• نوع ثابت

يتم تخزين هذا النوع من الحلويات على «القرص الصلب»

• نوع غير ثابت

يتم تخزين هذا النوع من الحلويات في «ذاكرة» المتصفح، وبالتالي يتطاير هذا النوع من المعلومات فور إغلاق المتصفح

وفق قواعد البروتوكول، على المتصفح أن يرسل الحلويات إلى الخادم الذي قام بانشائهافقط. فلا يتم إرسال الحلويات الخاصة بالخادم «أ» إلى الخادم «ب» و كذلك أيضا لا يتم إرسال الكوكيز الخاصة بالخادم «ب» إلى الخادم «أ»

تخيل أنك في مكتبة عامة، وأنك تود الإشتراك في المكتبه، ثم تخيل أنك بعد إتمام الإجراءات قمت بالتجول في المكتبه، وفجأة ظهر لك أحد الموظفين وسألك هل أنت عضو في المكتبة؟ إنك سوف تقول له صادقا «نعم»، لكن قد يطالبك الموظف باظهار بطاقة العضويه كدليل

وفق قواعد البروتوكول، فان توجيه «Set-Cookie» يقوم بتحديد التالي:

• اسم المتغير (Cookie Name)

اسم المتغير الذي يحتويه الحلويات

• قيمه المتغير (Cookie Value)

قيمة ذلك المتغير

• المسار (Path)

المسار الذي يحدد مجال تلك الحلويات، فالمسار «/» يعني أن على العميل إرسال تلك الحلويات لكل الصفحات والتطبيقات داخل مجال الجذر الرئيسي. والمسار «/shoppingcart» معناه أن العميل يجب عليه إرسال الحلويات للصفحات أو التطبيقات الواقعه في المجلد «/shoppingcart» فقط، وبالتالي لن يقوم العميل بارسال الحلويات إلى الصفحات أو التطبيقات الواقعه في المجلد «/users» على سبيل المثال، وهكذا…

• الصلاحية (Expiration)

هو تاريخ إنتهاء صلاحية الحلويات، وبالتالي يتم إستعمال تلك الحلويات طالما لم تنته صلاحيتها بعد

• آمن (Secure)

هذا التوجيه يحدد ما إذا كانت الحلويات يتم إرسالها عن طريق HTTP أو HTTPS. وعدم وجود ذلك التوجيه معناه – ضمنيا – أن الحلويات يتم إرسالها عن طريق HTTP. ولمزيد من الأمان، يفضل إرسال الحلويات – خاصة المهمه – عن طريق HTTPS

• النطاق (Domain)

النطاق الذي قام بارسال تلك الحلويات، وبالتالي يمنع بتاتا إرسال الحلويات الخاصه بنطاق ما إلى نطاق آخر. وهذا مبدأ مهم في بناء المتصفحات، فعلى كل متصفح أن يقوم بوضع جدول ما – بطريقة أو بأخرى – يحدد عن طريقه من الموقع الذي قام بانشاء الحلويات الفلانيه، وبالتالي يتم إرسال الحلويات الخاصه بذلك الموقع إليه دونا عن المواقع الأخرى.

Date (السطر رقم 6)

Date: Fri, 17 Jun 2011 23:15:30 GMT

6

إن هذا التوجيه يحدد اليوم والوقت الذي تم فيه إنشاء الرد. على الخادم أن يرسل هذا التوجيه إلى العميل حتى يستطيع «النقد» (Cache) – سواءا كان خاصا أو عام – تحديد تاريخ صلاحية النسخه المخزنه، ومن ثم يقوم بالرجوع إلى التوقيت الذي تم فيه خدمة الطلب. إن «النقد» عن طريق توجيه «Date» يستطيع أن يحدد ما إذا كان الطلب اللاحق لمصدر ما قد تجاوز فتره الصلاحية أم لا. و بالنسبه للعميل، فان إرسال هذا التوجيه اختياري تماما.

إن الـ«هيئة» (Format) المفضله لتوجيه «Date» هي التوقيت الدولي المتعارف عليه «GMT»^([7]) – توقيت جرينيتش –  ولا يفضل استخدام توقيت محلي (Local).

Server (السطر رقم 7)

Server: gws

7

إن هذا التوجيه يعطي بعض المعلومات عن الخادم الذي قام باجابة الطلب. هناك عدد من الصعب حصره من خوادم الويب (أو خوادم تطبيقات الويب)، لذا سوف نعرض بعضها:

خادم الويب	تفاصيل	مفتوح المصدر؟
Server: Apache	خادم الويب من مؤسسة «Apache»	نعم
Server: Microsoft-IIS	خادم الويب الخاص بنظام النوافذ	لا
Server: gws	خادم الويب الخاص بجوجل. طبقا لجوجل فان هذا الخادم عباره عن نسخه مفصله من خادم ويب يعمل على نظام لينوكس. وطبقا لجوجل (أيضا)، فان خادم الويب هذا ليس مبنيا على خادم الويب الشهير «Apache»	لا
Server: WEBrick	خادم يعمل من خلال نظام «Ruby on Rails» ليساعد المطورين في اختبار تطبيقات الويب	نعم
Server: Oracle-HTTP-Server	خادم الويب من «Oracle». مبني على خادم الويب «Apache»	لا
الجدول كذا-كذا بعض خوادم الويب المعروفه

تحذير

لا يفضل إعطاء بيانات تفصيليه عن الإصدار الخاص بخادم الويب، فان هذا يساعد الهاكرز في تحديد ما يبحثون عنه من التهديدات المحتمله لهذا الإصدار بدقة أكبر. لذا عليك أن تحدد ما هي المعلومات التي سوف تعطيها للعميل من خلال التوجيه «Server». يمكنك فعل ذلك عن طريق توصيفات خادم الويب (راجع ملفات المساعدة الخاصه بخادم الويب الذي تستخدمه). واذا كنت مصابا – مثلي!، وشأن كل العاملين في نظم حماية الحاسب – بعقدة الإضطهاد من نوع متفاقم وغير قابل للشفاء!، فيمكنك دوما تعديل توجيه «Server» ليعطي معلومات مخادعة تماما عن خادم الويب الذي تستعمله، فاذا كان خادم الويب من نوع «Microsoft-IIS» فيمكنك تعديل التوجيه ليكون – مثلا – «Apache»، وبالتالي فان الهاكرز سوف يستخدمون كل مافي جعبتهم من أسلحه وتهديدات ضد خادم الويب «Apache»! ويمكنك أن تفترض – والحال هكذا – أن محاولات الإختراق سوف تبوء بالفشل، والسبب بسيط، فان ما قد ينجح ضد برنامج – مثل خادم الويب عامة – لا يعني بالضرورة نجاحه ضد برنامج آخر – مثل خادم ويب آخر. أرجو أن تلاحظ هنا أنني أتكلم عن خادم الويب، وليس عن تطبيقات الويب.

Content-Length (السطر رقم 8)

Content-Length: 222

8

هذا التوجيه يحدد حجم محتوى الرد – أي محتوى الرساله دون التوجيهات – بوحدة «بايت» (Byte). إن هذا التوجيه ضروري في الردود التي تحتوي على جسم الرساله، أما الردود التي لا تحتوي على جسم الرساله – مثل الرد الناتج عن طلب ما باستخدام وسيلة «Head» أو الردود التي يتم إرسالها عبر عدة قطع أو أكثر من «كتلة» (Chunk) – فهو غير مطلوب بطبيعة الحال.

أحيانا لا يعلم خادم الويب ما هو حجم البيانات المرسله، وبالتالي لا يستطيع حساب حجمها، ومن ثم يتم استبدال «Content-Length» بتوجيه آخر هو توجيه «Transfer-Encoding: chunked» ومن ثم يتم إرسال الرد عبر عدة قطع أو كتل، ويتم تحديد حجم الكتله قبل إرسال محتوى تلك الكتله.

على سبيل المثال، هذا هو رد الخادم الذي تم إرساله عبر عدة «كتل»:

HTTP/1.1 200 OK

Content-Type: text/plain

Transfer-Encoding: chunked

 

4

Test

 

9

Test Test

 

11

My name is Hytham

لاحظ أن حجم الكتله يتحدد باستخدام «النظام السداسي عشر» وليس النظام «العشري»

إن كلا من توجيه «Content-Length» و توجيه «Transfer-Encoding» يساعدان العميل في معرفه إذا كان محتوى الرساله قد وصل كاملا أم تم قطعه في نقطه ما.

X-XSS-Protection (السطر رقم 9)

X-XSS-Protection: 1; mode=block

9

قامت مايكروسوفت بتطوير إضافه لمتصفح Internet Explorer الإصدار رقم 8 كمحاولة لاحتواء هجوم الكود العابر للموقع. وفقا لمايكروسوفت، فان استخدام ذلك التوجيه الجديد من متصفح يدعم ذلك التوجيه – مثل Internet Explorer – فان المتصفح سوف يحاول تفادي هذا النوع من الهجوم عن طريق تعديل الصفحه المحتويه على الكود بحيث يقوم بتعطيل خاصيه كود العميل (Client Script) – مثل JavaScript أو VBScript، ويتم إظهار رساله للعميل مفادها «قام Internet Explorer بتعديل الصفحه ليمنع هجوم محتمل لـ”الكود العابر للموقع”».

يمكن للمطور غلق تلك الخاصيه باستخدام القيمه «صفر» للتوجيه «X-XSS-Protection»

سطر خالي (السطر رقم 10)

إن هذا السطر هو الذي يحدد إنتهاء رأس الرساله بكل ما يحتويه من توجيهات، وأن الباقي – إن وجد – هو محتوى الرساله.

وفقا لقواعد البروتوكول، على كل توجيه أن ينتهي بمجموعة الأحرف «CR» ثم «LF» – الممثله بالكود السداسي عشر من مجموعة حروف «ASCII» 0x0a و 0x0d على التوالي. يمكنك اعتبارها مثل حرف الفاصلة المنقوطه «;» الذي يحدد نهاية السطر في الكثير من لغات البرمجه.

ووفق قواعد البروتوكول أيضا، لابد من فصل توجيهات الرسالة عن محتواها – إن وجد – بسطر خالي، هذا السطر الخالي يحتوي فقط على مجموعة الحروف «CR» ثم «LF».

عندما تقوم بمعالجة النصوص باستخدام برنامج معالجة بسيط – كـ «Notepad» – فإن زر الإدخال الذي تقوم بالضغط عليه لتبدأ الكتابة من أول سطر جديد يقوم نظام التشغيل أو البرنامج باستخدام حرف أو إثنين من حروف التحكم – الغير مطبوعة – في مجموعة حروف «ASCII» التاليه:

1. الحرف «CR» (Carriage Return)

• الكود السداسي عشر هو «0D»
• الكود العشري هو «13»
• الرمز البرمجي هو «\r»
• يقوم بنقل مؤشر الكتابة (Cursor) إلى أول السطر الحالي (السطر الذي كنت تكتب فيه الآن)

1. الحرف «LN» (Line Feed)

• الكود السداسي عشر هو «0A»
• الكود العشري هو «10»
• الرمز البرمجي «\n»
• يقوم بنقل المؤشر سطرا واحدا للأسفل

الفارق بين حرفي التحكم يظهر بوضوح عند استخدام لغات البرمجه، فلدى استخدام الحرف «LN» – الذي يرمز له في الكثير من لغات البرمجه بالرمز «\n»، فان المؤشر سوف يكون في أول خانة من السطر الجديد. أما إذا تم استخدام الحرف «CR» – الذي يرمز له غالبا بالرمز «\r» فان المؤشر سوف يقوم بالعودة إلى الخانة الأولى في السطر الحالي.

إن الكثير من لغات البرمجه المختلفه تعتمد أسلوب لغة «C» في إنشاء سطر جديد وذلك باستخدام الرموز البرمجيه السابق ذكرها.

تفسر أنظمه التشغيل الضغط على زر «الإدخال» تفسيرا مختلفا عن بعضها البعض:

نظام التشغيل	رمز «الإدخال»
النوافذ، MS-DOS	CR+LF
Mac OS	CR
Unix و Linux و FreeBSD	LF
بروتوكول نقل النص الفائق	CR+LF
الجدول كذا – كذا الإختلافات بين نظم التشغيل المختلفه في تفسير زر «الإدخال»

كما يوضح الجدول السابق، فان بروتوكول نقل النص الفائق يحتم استخدام مجموعة الحروف «CR+LF» كنهاية السطر – أي في نهاية رأس الرسالة وفي نهاية كل توجيه وفي السطر الخالي الذي يفصل بين توجيهات الرسالة وجسمها إن وجد.

جسم الرسالة (السطر رقم 11)

هي البيانات التي سوف يقوم المتصفح بعرضها للعميل. قد تكون هذه المعلومات نصيه – كنصوص HTML أو مجرد نص بسيط Plain Text – وقد تكون صور وخلافه.

الطلب (Request) رقم 2

 هذا هو الطلب الثاني الذي يقوم به العميل:

السطر رقم	محتوى السطر
1	GET / HTTP/1.1
2	Host: www.google.com.eg
3	User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
4	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5	Accept-Language: en-us,en;q=0.5
6	Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
7	Keep-Alive: 115
8	Connection: keep-alive
9

لا يختلف هذا الطلب عن الطلب السابق سوى في توجيه «Host». لاحظ أن الحلويات التي قام الخادم بارسالها في الرد الأول لم يتم إرسالها هاهنا لسبب بسيط، أن «نطاق» الحلويات كان «.google.com» وليس «.google.com.eg» وبالتالي لن يرسل المتصفح الحلويات الخاصه بـ «.google.com» إلى «.google.com.eg»

الرد (Response) رقم 2

 هذا هو الرد الثاني الذي أرسله الخادم (سوف نقوم بالتحدث عن بعض التوجيهات الجديده التي لم تتكرر في الرد الأول):

السطر رقم	محتوى السطر
1	HTTP/1.1 200 OK
2	Date: Sat, 18 Jun 2011 17:59:05 GMT
3	Expires: -1
4	Cache-Control: private, max-age=0
5	Content-Type: text/html; charset=UTF-8
6	Set-Cookie: PREF=ID=2160b4aadebe0fa5:FF=0:TM=1308419945:LM=1308419945:S=S2baa3tV5hzcjH8z; expires=Mon, 17-Jun-2013 17:59:05 GMT; path=/; domain=.google.com.eg
7	Set-Cookie: NID=48=JqzrjjkeeQ08C3zJ-EwAEeEPP9jnxvnov-_SbZcrSV1c4CYJoM3CZbbHH8dnMsRYkoGAepX9DRRqlbqk6hnXRAV9s7WJ-azBNALKNvc-g_xIirMeRjmNqu6bm5P7E0jQ; expires=Sun, 18-Dec-2011 17:59:05 GMT; path=/; domain=.google.com.eg; HttpOnly
8	Server: gws
9	X-XSS-Protection: 1; mode=block
10
11	<!doctype html><html><head><meta http-equiv=”content-type” content=”text/html; charset=UTF-8″><title>Google</title><script>window.google={kEI:”aef8TaD7Dc_A8QPa2vjgAw”,kEXPI:”28505,29822,30460,30536,30819″,kCSI:{e:”28505,29822,30460,30536,30819″,ei:”aef8TaD7Dc_A8QPa2vjgAw”,expi:”28505,29822,30460,30536,30819″},authuser:0 … (مقتطع)

Expires (السطر رقم 3)

3	Expires: -1

هنا يحدد الخادم تاريخ صلاحية المحتوى. لمساعدة «النقد» في تحديد صلاحية النسخ المحليه التي قام باحضارها سابقا، يقوم الخادم عن طريق التوجيه «Expires» بتحديد تاريخ الصلاحية الذي يتم إعتبار المحتوى المحلي «غير طازج» إذا تم تجاوز هذا التاريخ، وبالتالي يقوم المتصفح بعرض تلك النسخه المحليه «المحفوظه» للعميل طالما لم تتجاوز التاريخ المحدد. أما إذا تم تجاوز تاريخ الصلاحيه، فان على المتصفح أن يقوم بالإستعلام عن «حداثة» نسخة الخادم من ذلك المصدر، فاذا كانت نسخة الخادم لا تختلف عن النسخة المحفوظه، عرض المتصفح النسخة المحفوظه، أما إذا كانت نسخة الخادم أحدث، قام المتصفح باحضار تلك النسخة  «الطازجه» للمصدر المطلوب.

على الخادم إعطاء تاريخ محدد – مثل Fri, 17 Jun 2011 23:15:30 GMT –  وأي شيئ آخر يتم تفسيره على أن هذا الرد «منتهي الصلاحيه» وبالتالي لا يتم تخزينه في «النقد»، ومن ثم يتحتم على المتصفح إحضار نسخة «طازجة» – بطبيعة الحال – من الخادم^([8]).

في الرد السابق، قام خادم جوجل بتحديد الصلاحيه بـ «1-» (سالب واحد) وهذا معناه تحديدا أن على االمتصفح عدم تخزين نسخة محلية من هذا المحتوى حيث أن هذا المحتوى قد تجاوز تاريخ صلاحيته، وأن على العميل إحضار نسخه طازجه من هذه الصفحه إذا أراد طلبها مرة أخرى.

إن هذا التوجيه أصبح توجيها «متقاعدا» (Deprecated) حيث تم استبداله بتوجيه «Cache-Control»، إلا أن كثيرا من خوادم وتطبيقات الويب مازالت تستخدمه مع التوجيه «Cache-Control» لدعم الأنظمة والبرامج الغير حديثه.

Cache-Control (السطر رقم 4)

4	Cache-Control: private, max-age=0

بروتوكول نقل النص الفائق يعتمد أكثر من طريقة لتوضيح كيف يتم التعامل مع الصفحة من منظور «النقد» قبل أن تنتهي مدة صلاحيتها، من هذه الطرق ما يلي:

• «Cache-Control: public»

إن هذا التوجيه معناه أن الرد من الممكن وضعه في «النقد» سواءا كان ذلك النقد عاما أو خاصا.

• «Cache-Control: private»

هذا معناه أن على «النقد العام» أن لا يقوم بتخزين جزء أو كل الرد. أما «النقد الخاص» فيسمح له بذلك.

• «Cache-Control: no-cache»

هذا التوجيه معناه أن على المتصفح أن يقوم بمراجعة الخادم للتأكد من صلاحية المحتوى قبل عرض النسخة المحفوظة سابقا (في «النقد»).

• «Cache-Control: no-store»

هذا التوجيه  معناه أن هذا المحتوى غير قابل للتخزين في «النقد» إطلاقا، سواءا كان هذا النقد «عاما» أو «خاصا».

• «Cache-Control: max-age»

هذا التوجيه يحدد عدد الثواني التي يتم اعتبار المحتوى «طازجا» طالما لم يتم تجواز هذه الفتره. بعدها على المتصفح مراجعة الخادم للتأكد من صلاحية المحتوى قبل عرض النسخة المحفوظة. المتغير «max-age» يتبع بعدد يحدد عدد الثواني، على سبيل المثال «Cache-Control: max-age=90000» يقوم بتحديد يوم كامل قبل أن يتحتم على المتصفح مراجعة الخادم لمعرفه ما إذا كان المحتوى المخزن مازال «طازجا» أم لا.

إن وضع القيمة «صفر» كقيمة للمتغير «max-age» معناه أن على المتصفح عدم تخزين نسخة من المحتوى في «النقد» بالإضافه إلى إحضار نسخة «طازجة» دوما من الخادم كلما طلب العميل هذا المحتوى.

Set-Cookie (السطر رقم 7)

هناك بعض الملاحظات بالنسبه لهذا التوجيه:

1. يتم إرسال كل حلوى على حده في توجيه «Set-Cookie» خاص بها، وقد قام الخادم بارسال عدد 2 حلوى (السطر رقم 6 والسطر رقم 7)
2. نطاق الحلويات تم تغييره من «.google.com» إلى «.google.com.eg»
3. استخدم الخادم خاصيه «HttpOnly» لمحاولة احتواء خطورة الكود العابر للموقع، وسوف نتحدث عن تلك الخاصيه بالتفصيل في فصل «الكود العابر للموقع»

والآن سوف نتجاوز باقي الحزم الصادره والوارده للاختصار غير المخل، ومن ثم نقوم باعتراض الحزم لنحاكي عملية إرسال بعض البيانات من العميل إلى الخادم.

سوف نقوم بالولوج إلى البريد الإلكتروني الخاص بـ Gmail لنقوم باستعراض بعض الحزم المعترضه.

الطلب (Request)

بعدما قام العميل بملء استمارة الويب باسم المستخدم وكلمة السر خاصته ثم الإرسال، تم إرسال حزمه البروتوكول التاليه:

السطر رقم	محتوى السطر
1	POST /accounts/ServiceLoginAuth HTTP/1.1
2	Host: www.google.com
3	User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
4	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5	Accept-Language: en-us,en;q=0.5
6	Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
7	Keep-Alive: 115
8	Connection: keep-alive
9	Referer: https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=llya694le36z&scc=1&ltmpl=default&ltmplcache=2&from=login
10	Cookie: GAPS=1:FYwq9fPpmfPJqRkn9a1wruhNjR2OQg:Qh5338PbF0M9y9LH; GALX=rI1fm7ydKLA; PREF=ID=6d6b25c391719533:FF=0:TM=1308419848:LM=1308419848:S=1w-dsG2dpxBvYH3e; GMAIL_LOGIN=T1308418199048/1308418199048/1308418222316
11	Content-Type: application/x-www-form-urlencoded
12	Content-Length: 264
13
14	ltmpl=default&ltmplcache=2&pstMsg=1&dnConn=&continue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3F&service=mail&rm=false&dsh=2268669025351174338&ltmpl=default&ltmpl=default&scc=1&timeStmp=&secTok=&GALX=rI1fm7ydKLA&Email=ahmed&Passwd=1234&rmShown=1&signIn=Sign+in&asts=
جدول كذا – كذا طلب العميل لملئ إستمارة ويب

رأس الرسالة (السطر رقم 1)

الوسيلة التي يتم اتباعها – عادة – عندما يقوم العميل بملء استمارة ويب ببعض البيانات ثم إرسالها هي الوسيلة «POST». وهنا قام العميل بتحديد التطبيق الذي سوف يتعامل مع تلك الإستماره.

لاحظ أن الوسيلة «POST» لا تقوم بارسال البيانات في رأس الرسالة، بل تقوم بارسالها في «جسم الرسالة» – أي بعد انتهاء التوجيهات تماما – وهي عكس الوسيلة «GET» التي تقوم بارسال البيانات – إن وجدت – في رأس الرسالة. وهناك اختلاف آخر، أن على المتصفح حال استخدامه وسيلة «POST» أن يقوم بحساب حجم المحتوى المرسل – البيانات التي قام العميل بملئها في إستمارة الويب على سبيل المثال – ومن ثم يقوم بوضع حجم البيانات بـ «البايت» في توجيه «Content-Length» على عكس الوسيلة «GET» التي لا تقوم بذلك، وبالتالي لا يوجد حاجة لوضع توجيه «Content-Length» أصلا.

Referer (السطر رقم 9)

هذا التوجيه يتطوع باخبار الخادم بالموقع الذي «أحيل» منه العميل. ببساطه يقوم المتصفح بادراج ذلك التوجيه ليساعد الخادم على تنسيق جهوده لتصنيف عملاء الموقع وفق زيارتهم للصفحات المختلفه.

إن آلية عمل هذا التوجيه كالتالي، عندما تكون في الصفحة «أ» وتقوم بالنقر على رابط الصفحه «ب» – سواءا كانت الصفحة ب ضمن نفس نطاق الصفحة «أ» أم لا – فان المتصفح يقوم بادراج عنوان الصفحة «أ» في توجيه «Referer» عندما يقوم بطلب الصفحة «ب»، وهكذا.

إن توجيه «Referer» لا يتم إدراجه في حالة كتابة عنوان الصفحة المطلوبة في خانة عنوان المتصفح. بل يتم إدراجه فقط في حالة نقر العميل على رابط ما. لذا يمكنك القول أن الصفح التي تقوم بكتابة عناوينها في خانة العنوان لا يتم إدراجها في توجيه «Referer» حيث أنها نقطة البداية، بينما عندما تبدأ حركتك من هذا الصفحه باستخدام الروابط بكافة أشكالها – نصوص، صور، أزرار (Buttons) وغيرها – فان كل حركة لاحقة يتم إدراج عنوان الصفحة الحالية – سواءا العنوان المطلق (Absolute) أو النسبي (Relative) – في التوجيه «Referer» عند طلب الصفحة اللاحقة.

إذا كنت لا تود إدراج هذا التوجيه مطلقا، فانه يمكنك ذلك من إعدادات المتصفح. على سبيل المثال، إذا كنت تستخدم فايرفوكس، فاكتب «about:config» في خانة العنوان ثم اذهب إلى القيمة «network.http.sendRefererHeader» وعدلها بـ «0» (صفر).

Content-Type (السطر رقم 11)

إن هذا التوجيه يحدد نوع الوسائط «MIME» التي يحتوي عليها جسم الرسالة، كما أشرنا إلى ذلك آنفا – في الطلب رقم 1 التوجيه «Accept» (السطر رقم 4) وفي الرد رقم 1 التوجيه «Content-Type» (السطر رقم 4).

إن تحديد نوع الوسائط بـ «application/x-www-form-urlencoded» يعني أن العميل سوف يرسل بيانات خاصة باستمارة ويب.

Content-Length (السطر رقم 12)

هو عدد البيانات المرسله في جسم الرسالة بوحدة «بايت»، ومن حق الخادم إلغاء الطلب إذا كان عدد البيانات المعلن عنه في هذا التوجيه يختلف عن العدد الفعلي في جسم الرسالة.

جسم الرسالة (السطر رقم 13)

إن جسم الرسالة – الخاصه ببيانات استمارة الويب – لا ينفك عن متغيرات وقيم تلك المتغيرات. فهنا مثلا سوف تجد أن هناك العديد من المتغيرات وقيمها. فالمتغير Email يحتوي على القيمه التي قام المستخدم بملئها في الاستماره، وهي هنا  ahmed، ثم المتغير Passwd الذي يحتوي على القيمه 1234

تحذير

لا تعتمد مطلقا على بيانات قادمه من العميل، سواءا كانت تلك البيانات توجيهات في رأس الرساله أو بيانات في محتوى الرساله. إن كل توجيه – فضلا عن جسم الرسالة – يصدره المتصفح يمكن التلاعب به بكل سهوله. لا ترتكب خطأ فاحشا بالاعتماد على أي معلومات قادمه من العميل. بعض المطورون يعتمدون على بعض التوجيهات كتوجيه «Referer» الذي يحدد من أين أتى العميل، ومن ثم يتم تقرير إذا كان طلب العميل مصرح به أم لا. هذا خطأ فاحش بعضهم يعتمد على أن الكوكيز لا يمكن العبث بها! لهذا فهو يرسل كوكيز غير مشفرة ويسهل توقعها ومن ثم تزويرها (مثل أحد المواقع الذي يستخدم userid=1; كـكوكيز! إنه من السهل جدا عمل برنامج يقوم بتعديل الكوكيز السابقه ضمن حلقه (Loop) لجلب كل حسابات عملاء ذلك الموقع، Cookie: userid=1; ثم Cookie: userid=2; وهكذا دواليك)

خاتمه

إن بروتوكول نقل النص الفائق هو بروتوكول الشبكه العالميه العنكبوتيه أو الويب. وهو وإن كان أقل تعقيدا من بروتوكول TCP/IP إلا أنه في غايه الأهميه بالنسبه لمطور الويب. لذا على المطور ان يستثمر بعض الوقت في قراءة هذا البروتوكول. وأسهل طريقة لتعلم ذلك البروتوكول هو كتاب جيد و وسيط ويب. عن طريق الإثنين سوف تفهم وتراقب الرسائل الصادره والوارده من المتصفح والخادم. وعن طريق وسيط الويب يمكنك اجراء مزيد من الفحص لتطبيقات الويب التي قمت بتطويرها.

مصادر للإستزاده

• «بروتوكول نقل النص الفائق» ، طلب التعليق رقم 2616 (http://www.ietf.org/rfc/rfc2616.txt(
• «HTTP: The Definitive Guide» (دار نشر O’Reilly)

---

([1]) يمكنك القيام بذلك من برنامج Paros نفسه عن طريق قائمة الأدوات (Tools) ثم الخيارات (Options)، ثم الوسيط المحلي (Local Proxy) ومن ثم قم بتعديل المنفذ – المضبوط فطريا على 8080 – لأي منفذ آخر

([2]) قديما كان على المطور أن يعمل كل شيء بنفسه، لكن هذا لم يعد الحال يومنا هذا، لذا أرى أن الإقتراب والنظر إلى ما تحت غطاء محرك السيارة سوف يعطي الكثير من المعلومات والخبرات المفيده التي لا غنى عنها للمطور

([3]) إن هناك اختلافا يسيرا بين استخدام وسيط وبين استخدام إضافه خاصه للمتصفح مثل إضافه «Live HTTP Headers»، فالوسيط سوف يقوم بتعديل بسيط لبعض التعليمات التي سوف يتم إرسالها عن طريق المتصفح، بينما الإضافه السابقه لن تقوم بعمل أيه تعديلات

([4]) يمكنك مراجعة http://www.useragentstring.com/ للحصول على قائمه طويله بكل بالتوجيه «User-Agent» الخاص بالعديد من متصفحات الويب المختلفه

([5]) كانت السعة التخزينيه في ذلك الوقت في غاية الأهميه، فلم تكن التكنولوجيا قد تطورت بعد للوصول إلى السعات التخزينيه الهائله التي نتسخدمها الآن، لذا كان هناك «شح» في استخدام السعه التخزينيه المناسبه. وهناك مثال آخر لذلك الشح – المفهوم – وذلك عندما ظهرت المشكله المعروفه بـ «Y2K» – أو مشكله عام 2000 – حيث تم تصميم كثير من أنظمه الحاسب بحيث تستخدم خانتين فقط لتمثيل السنه، وبالتالي كانت هناك مشكله عندما ننتقل من عام 1999 إلى عام 2000 حيث أن تلك الأنظمه سوف تنتقل من 99 إلى 00 – دون ترحيل الواحد إلى خانة المئات ومن ثم خانة الألوف لأنهما غير موجودان أصلا – وبالتالي سوف يصبح العام 2000 هو العام 1900 وقد كان الخوف أن يؤدي هذا العيب التصميمي إلى كثير من الكوارث

([6])كان المطور «لوي مونتولي» الذي كان يعمل في شركه Netscape Communications يقوم بتطوير تطبيق تجارة إلكترونيه (E-Commerce) لأحد عملاء الشركه عام 1994، وقد قام المطور بابتداع أسلوب جديد وفعال لحل مشكله «عربة التسوق» (Shopping Cart). إن ذلك المطور ساهم بشكل فعال في تطوير أفضل أسلوب حالي لتحديد العملاء وإنشاء جلسة دائمه (Persistent Session). لكن هل لم يكن لديه مسمى آخر لذلك الأسلوب الجديد سوى «الحلويات» أو «Cookies»؟ إن هذا المسمى يعد من أسوأ المسميات أو المصطلحات، فهو يدلل على شيء بعيد كل البعد عن المعنى البديهي لذلك المسمى!

([7]) إن توقيت GMT هو التوقيت المحدد بخط الطول صفر والمار ببلدة «جرينتش» في بريطانيا، ويتم حساب توقيت البلدان والدول حسب موقعها «شرق» أو «غرب» خط الطول صفر.

([8]) وفق قواعد البروتوكول، على الخادم أن يرسل تاريخا محددا في توجيه «Expires»، لكن هناك الكثير من الخوادم وتطبيقات الويب لا تتبع هذا النظام إذا كانت تريد منع تخزين الصفحه في «النقد»، لذا فانهم يعمدون إلى وضع القيمة صفر أو قيمة سالبة كقيمة للتوجيه «Expires». بينما يقومون بوضع قيم وقتيه صحيحه – كما نص عليه البروتوكول مثل تاريخ اليوم والساعه كذا -  إذا كانوا يريدون تخزين الصفحة في النقد لفترة ما.