يقصد كل طلب في HTTP موردا واحدا، ومحدد هذا المورد في كل طلب هو الرابط (Uniform Resource Locator, URL). فالخادم لا يفهم أوصافا لغوية عامة مثل «صفحة المقالات بالعربية، الصفحة الثانية منها»، بل يحتاج إلى عنوان مكتوب بصيغة قياسية متفق عليها، ليعرف بدقة متناهية أي مورد يقصده العميل.
ويبدو الرابط في شريط العنوان سطرا واحدا متصلا، غير أن لكل جزء فيه وظيفة مستقلة تماما. ومن تمايز هذه الوظائف تنشأ مواقف عملية يلقاها مطورو الويب: قيمة بحث تحتوي على & تصل إلى الخادم مقسومة إلى قيمتين، وعنوانان يشتركان في اسم النطاق نفسه يعاملهما المتصفح كجهتين مختلفتين لمجرد أن أحدهما يبدأ بـ http والآخر بـ https.
المخطط والمضيف والمنفذ: كيف يصل المتصفح إلى الخادم
خذ هذا الرابط مثالا:
https://blog.example.com/articles/url-anatomy?lang=ar&page=2#sourcesأول ما يظهر في الرابط كلمة تسبق النقطتين الرأسيتين: https. تسمى هذه الكلمة المخطط (scheme)، وتسميها بعض المراجع والأدوات بروتوكولا، وهي تحدد القواعد التي تحكم الحوار مع الطرف الآخر. فالمخطط http يعني حوارا عبر قناة مكشوفة، وhttps يعني الحوار نفسه عبر قناة مشفرة. ولذلك يكفي تغيير المخطط وحده ليتغير نوع الاتصال كله، ولو تطابق بقية الرابط حرفا بحرف.
ثم يأتي بعد الشرطتين المائلتين // اسم الجهة التي تستضيف المورد: blog.example.com. يسمى هذا الجزء المضيف (host)، وهو في الغالب اسم نطاق (domain name) كما في المثال، وقد يكون عنوانا رقميا مباشرا يسمى عنوان IP (IP address). واسم النطاق ليس عنوانا ماديا يتصل به الجهاز مباشرة، بل اسم رمزي يترجمه نظام أسماء النطاقات (Domain Name System, DNS) إلى عنوان IP قبل فتح الاتصال، وهو نظام مستقل تماما عن HTTP.
ويأتي بعد المضيف رقم اختياري تفصله عنه نقطتان رأسيتان، هو المنفذ (port). فعلى الجهاز الواحد قد تعمل برامج خوادم متعددة في الوقت نفسه، ولا يكفي عنوان الجهاز وحده لتحديد البرنامج المقصود؛ لذلك يستمع كل برنامج للاتصالات عند رقم يميزه، وهذا الرقم هو المنفذ. ولكل مخطط منفذ افتراضي: 80 لـ http و443 لـ https. فإذا كان الخادم يستقبل الاتصالات عند المنفذ الافتراضي جاز إغفال الرقم كما في المثال، أما إذا كان ينتظرها عند منفذ آخر وجب ذكره صراحة، مثل https://blog.example.com:8443/.
وتطلق مواصفة الروابط على المضيف ومنفذه اسما جامعا هو السلطة (authority). وقد كان يجوز قديما أن يسبق المضيف اسم مستخدم وكلمة مرور بالصيغة https://user:pass@example.com/ كجزء من بيانات المستخدم (userinfo). وهذه الصيغة مهجورة (deprecated) في المواصفة القياسية نفسها، لأنها تكشف كلمة المرور صراحة لكل من يشاهد الرابط أو ينسخه أو يسجله. ويمنع متصفح Chrome تحميل الموارد الفرعية في الصفحات عبر روابط تتضمن بيانات الاعتماد هذه.
المسار والاستعلام: أي مورد بالضبط
أوصلت الأجزاء السابقة المتصفح إلى برنامج بعينه على خادم بعينه، لكنها لم تحدد بعد ما المطلوب من هذا البرنامج، والخادم الواحد قد يستضيف ملايين الموارد المختلفة. وهنا يأتي دور الجزء الذي يلي المضيف والمنفذ: /articles/url-anatomy.
يسمى هذا الجزء المسار (path)، وهو الذي يحدد المورد المستهدف داخل ذلك الخادم. ويكتب في صورة مقاطع (segments) تفصل بينها الشرطة المائلة /، ففي رابط المثال مقطعان: articles ثم url-anatomy. وتشبه هذه المقاطع ظاهريا تسلسل مجلدات ينتهي باسم ملف، وقد تمثل مسارا حقيقيا على قرص الخادم في بعض المواقع، غير أن ذلك ليس شرطا؛ فالمورد قد يبنى لحظيا عند ورود الطلب من قاعدة بيانات، ويكون المسار حينها معرفا منطقيا يفهمه تطبيق الخادم ويوجهه إلى الشيفرة المسؤولة عنه، لا موضع ملف حقيقي على القرص.
وفي التعامل مع المسار أمر عملي يسهل إغفاله: حساسية حالة الأحرف (case sensitivity). فالمخطط والمضيف غير حساسين لحالة الأحرف (case-insensitive)، ولا يتغير معناهما بكتابتهما بحروف كبيرة أو صغيرة؛ ولذا فإن BLOG.example.com وblog.example.com يمثلان المضيف نفسه. أما بقية أجزاء الرابط فحساسة لحالة الأحرف (case-sensitive)، ولذلك يعد /Articles و/articles مسارين مختلفين تماما. وقد تعامل بعض الخوادم المسارين معاملة واحدة إذا كانت تقرأ ملفاتها مباشرة من نظام ملفات لا يفرق بين الحالتين، غير أن هذا سلوك خاص بإعدادات تلك الخوادم لا قاعدة عامة في بنية الروابط، فلا يصح الاعتماد عليه مطلقا.
ويأتي بعد المسار جزء يبدأ بعلامة الاستفهام: ?lang=ar&page=2. يسمى هذا الجزء الاستعلام (query)، ويحمل معاملات تكمل تحديد المطلوب، كلغة العرض أو معيار التصفية أو رقم صفحة النتائج. وهيئته في المثال أزواج من مفتاح وقيمة: يفصل الرمز = بين المفتاح وقيمته، ويفصل الرمز & بين كل زوج وتاليه. ففي المثال زوجان: المفتاح lang وقيمته ar، والمفتاح page وقيمته 2.
وهذه الهيئة شائعة للغاية، غير أنها عرف برمجي لا قاعدة إلزامية في المواصفة. فمواصفة الروابط تكتفي باشتراط أن يبدأ الاستعلام بعلامة الاستفهام ? وأن ينتهي عند علامة # أو عند نهاية الرابط، وتترك ما بينهما كنص خام يفسره تطبيق الخادم كما يشاء. أما صيغة key=value&key=value فهي الطريقة التي ترسل بها نماذج HTML بياناتها تلقائيا في الاستعلام، ومن شيوع النماذج شاعت هذه البنية حتى أصبحت الصيغة القياسية المتوقعة.
والاستعلام جزء أصيل من هوية المورد لا إضافة ثانوية؛ فالرابطان /search?q=http و/search?q=url يقصدان موردين مختلفين ونتيجتين مختلفتين وإن اتفق مسارهما. وفي المقابل، ثمة اختلاف ظاهري في الكتابة لا يغير المورد: https://example.com وhttps://example.com/ يقصدان المورد نفسه تماما، لأن المسار الخالي يعامله البروتوكول كأنه المسار الجذري /.
المعرف الجزئي (fragment): موضع داخل المورد لا مورد آخر
بعد تحديد المورد وتفاصيله بالمسار والاستعلام، يتبقى من رابط المثال جزء أخير: #sources. يسمى هذا الجزء المعرف الجزئي (fragment identifier)، ويطلق عليه في المراجع الإنجليزية غالبا fragment، وتسميه بعض المراجع المرساة (anchor). ووظيفته ليست طلب مورد آخر على الخادم، بل الإشارة إلى موضع محدد داخل المورد نفسه بعد وصوله إلى المتصفح: كعنوان فرعي في المقال يقفز إليه المتصفح مباشرة، أو توقيت زمني في مقطع صوت أو فيديو تبدأ منه نقطة التشغيل.
ولهذا التمايز نتيجة صريحة تنص عليها المواصفات القياسية: يعزل المتصفح المعرف الجزئي عن بقية الرابط قبل صياغة الطلب وإرساله، ويظل تفسيره وتطبيقه مهمة حصرية للعميل وحده أيا كان المخطط المستخدم. فالخادم يرسل المورد ككتلة واحدة كاملة، أما التمرير إلى موضع معين فمهمة البرنامج الذي يعرض المحتوى على جهاز المستخدم؛ ولهذا السبب لا يصل ما بعد الرمز # إلى الخادم قط، ولا يراه الخادم في أي مرحلة.
تشبيه
يشبه المعرف الجزئي رقم صفحة تدونه في ملاحظاتك الشخصية حين تطلب كتابا من مكتبة. فالمكتبة تناولك الكتاب كاملا ولا يعنيها رقم الصفحة في شيء، ثم تتولى أنت بنفسك فتح الكتاب على الصفحة المطلوبة بعد استلامه.
ويترتب على ذلك أثران عمليان بالغا الأهمية:
الأول: لا يظهر المعرف الجزئي في سجلات وصول الخوادم ولا في أدوات التحليل والإحصاء التي تعمل من جهة الخادم، لأن الخادم لم يستلمه أصلا عبر الشبكة.
والثاني: الانتقال بين مواضع مختلفة داخل الصفحة نفسها بتغيير ما بعد # فقط لا يرسل طلبا جديدا عبر الشبكة؛ فالمورد محمل بالفعل في ذاكرة المتصفح ولم يتغير المورد المطلوب من الخادم.
ما يصل إلى الخادم وما يبقى في المتصفح
لا يسافر الرابط كاملا ككتلة واحدة في رسالة الطلب. فالمتصفح يحلل الرابط أولا ويوزع أجزاءه بحسب ثلاث وظائف رئيسية: أجزاء يستهلكها لفتح الاتصال، وأجزاء يرسلها نصا في الرسالة، وجزء يحتفظ به لنفسه ولا يخرجه إلى الشبكة.
يبدأ المتصفح بالمخطط والمضيف والمنفذ ليؤسس الاتصال بالطرف الآخر قبل إرسال أول بايت من الطلب: يترجم اسم المضيف عبر DNS إلى عنوان IP، ثم يفتح اتصالا شبكيا عند المنفذ المحدد صراحة أو المنفذ الافتراضي للمخطط، ويجري مصافحة التشفير لتأمين القناة إن كان المخطط https.
وبعد تأسيس الاتصال، يرسل المتصفح في الرسالة المسار والاستعلام مدمجين معا، ويسمى اجتماعهما هدف الطلب (request target)؛ فإن كان المسار خاليا تماما أرسل المتصفح الشرطة المائلة / مكانه. ويرسل المتصفح كذلك اسم المضيف، على الرغم من أنه استعمله بالفعل لتحديد خادم الوجهة؛ والسبب أن الخادم الفيزيائي الواحد قد يستضيف مئات المواقع والنطاقات المختلفة خلف عنوان IP واحد، فلا يتبين الخادم أي موقع يقصده الزائر إلا إذا نص الطلب على اسمه صراحة. ففي HTTP/1.1 يرسل المضيف في ترويسة (header) تدعى Host، وفي HTTP/2 وHTTP/3 يرسل في حقل ترويسة زائفة يؤدي الغرض نفسه يدعى :authority، ويرافقهما رقم المنفذ إن لم يكن هو المنفذ الافتراضي.
أما المخطط، فيعرفه الخادم في HTTP/1.1 ضمنيا من طبيعة القناة التي استقبل عبرها الاتصال (سواء كانت مشفرة عبر منفذ 443 أو مكشوفة عبر منفذ 80)، في حين ترسله النسختان الأحدث صراحة ضمن حقل الترويسة الزائفة :scheme. وإن اشتمل الرابط على اسم مستخدم وكلمة مرور، فإنهما يستبعدان تماما ولا يدخلان في هدف الطلب ولا في حقل المضيف.
أما المعرف الجزئي فلا يرسل إلى الخادم إطلاقا في أي نسخة من نسخ البروتوكول دون استثناء.
ويوضح الجدول التالي مصير كل جزء من رابط المثال عند إرسال الطلب:
scheme https -> opens an encrypted connection on port 443
host blog.example.com -> sent (Host header)
path /articles/url-anatomy -> sent
query lang=ar&page=2 -> sent
fragment sources -> never sentولهذا التوزيع نتيجة أمنية وعملية مباشرة: الاستعلام يصل إلى تطبيق الخادم بنصه الكامل كما دون في الرابط، ويدون تلقائيا في سجل الوصول (access log) الخاص بالخادم؛ فخادم nginx مثلا يسجل في إعداده الافتراضي سطر كل طلب بما يحمله من مسار واستعلام.
# فلا يغادر جهازك إطلاقا.ولطول الرابط الإجمالي حد عملي تفرضه الخوادم والوسطاء. فمواصفة HTTP القياسية لا تفرض حدا أقصى لطول الرابط، لكنها توصي بأن تدعم الخوادم والمتصفحات روابط لا يقل طولها عن 8000 بايت. وقريبا من هذا الحد استقرت الإعدادات الافتراضية في أشهر برمجيات الخوادم: نحو 8 كيلوبايت في nginx (عبر ضبط large_client_header_buffers)، و8190 بايت في Apache (عبر LimitRequestLine)، ويرد nginx عند تجاوز هذا الحد برمز الحالة 414 (414 URI Too Long). لذلك فإن البيانات الضخمة مكانها الصحيح هو جسم الطلب لا استعلام الرابط.
الحروف المحجوزة والترميز بالنسبة المئوية
لا تعامل جميع الرموز في الرابط كبيانات نصية عادية؛ فبعضها يملك دورا تركيبيا بنيويا يحدد فواصل العنوان: فالشرطة المائلة / تفصل بين مقاطع المسار، وعلامة الاستفهام ? تفتتح جزء الاستعلام، وعلامة & تفصل بين متغير وآخر، وعلامة # تبدأ المعرف الجزئي. وتصنف المواصفات القياسية هذه الرموز تحت اسم الحروف المحجوزة (reserved characters). وتنشأ المشكلة التقنية عندما تحتوي القيمة الفعلية للبيانات على أحد هذه الرموز؛ فلو كتب المستخدم استعلام بحث يحتوي على الرمز & بالصيغة ?q=HTTP&HTTPS، لتفكك الاستعلام لدى الخادم إلى حقلين مختلفين: حقل أول باسم q وقيمته HTTP، وحقل ثان مستقل باسم HTTPS من دون قيمة، مخالفا قصد السائل تماما.
ويكمن الحل في تجريد الحرف من وظيفته البنيوية عبر إعادة صياغته: علامة النسبة المئوية % متبوعة برقم من خانتين يمثل القيمة الرقمية لبايت الحرف في النظام الست عشري (hexadecimal)، الذي يستخدم الأرقام من 0 إلى 9 والحروف من A إلى F. وتسمى هذه الصيغة الترميز بالنسبة المئوية (percent-encoding). وبناء على هذه القاعدة، يتحول الرمز & إلى %26، والشرطة / إلى %2F، والمسافة إلى %20. وتكتب قيمة البحث السابقة بالصيغة ?q=HTTP%26HTTPS، فيستقبلها الخادم كمتغير واحد يحمل القيمة النصية الكاملة HTTP&HTTPS.
ولتمثيل المسافة داخل الاستعلام تحديدا صيغة ثانية واسعة الاستخدام هي علامة الجمع +. فالمواصفة التاريخية لنماذج HTML ترمز المسافات بعلامة + عند إرسال البيانات عبر الاستعلام، وتفهم مكتبات معالجة الطلبات في الخوادم هذه الدلالة تلقائيا، فتقرأ ?q=a+b كقيمة نصية هي a b. غير أن هذه المعاملة مقتصرة تماما على الاستعلام: ففي مسار الرابط تظل علامة + علامة جمع حقيقية، ويكون المسار /a+b مسارا نصه الحرفي a+b. ولأن علامة + تفسر كمسافة في الاستعلام، فإنها ترمز هي نفسها إلى %2B متى ما كانت جزءا أصيلا من النص المطلوب إرساله في الاستعلام كرمز جمع.
ولأن الترميز يجرد الحرف من وظيفته البنيوية، فإن وجود الحرف المرمز يغير بنية الرابط ولا يطابق نظيره غير المرمز؛ فالمسار /p/a/b مسار يتكون من ثلاثة مقاطع منفصلة، بينما المسار /p/a%2Fb مسار من مقطعين فقط، نصه في المقطع الثاني هو a/b.
وتعالج القاعدة نفسها الحروف غير اللاتينية في المسار والاستعلام؛ إذ لا تسمح بنية الرابط الأصلية إلا بمجموعة محددة من الحروف اللاتينية والأرقام وبعض الرموز. وأي حرف خارج هذا النطاق يفكك أولا إلى بايتاته المقابلة وفق نظام ترميز UTF-8، ثم يكتب كل بايت بصيغة النسبة المئوية. وبما أن كل حرف عربي يشغل بايتين في ترميز UTF-8، فإن كلمة مثل شبكة المكونة من أربعة أحرف تتحول إلى سلسلة من ثمانية بايتات مرمزة في استعلام البحث:
https://blog.example.com/search?q=%D8%B4%D8%A8%D9%83%D8%A9ولا يتعارض هذا الترميز مع ما يشاهده المستخدم في شريط العنوان؛ فالمتصفحات الحديثة تفك الترميز وتعرض الكلمات بحروفها العربية لتيسير قراءتها على الإنسان، لكنها عند نقل الطلب عبر الأسلاك ترسل البايتات المرمزة بنظام النسبة المئوية كما تطلب البروتوكولات.
ويستثنى اسم المضيف من قاعدة الترميز بالنسبة المئوية. فاسم النطاق المكتوب بحروف غير لاتينية لا يستخدم النسبة المئوية، بل يترجم وفق معيار أسماء النطاقات الدولية إلى صيغة لاتينية بديلة تدعى بوني كود (Punycode)، وتبدأ دائما بالسابقة xn--؛ فكلمة مثال في اسم نطاق تتحول إلى xn--mgbh0fb. ويعود سبب هذا الاستثناء إلى أن نظام أسماء النطاقات (DNS) صمم قديما ليتعامل حصرا مع الحروف اللاتينية والأرقام والشرطة، فكان لا بد من تمثيل الأسماء الدولية بصيغة لاتينية صالحة تقبلها خوادم الأسماء دون تعديل بنيتها.
الروابط النسبية: عنوان ناقص يكمله المتصفح
لا تكتب أغلب الروابط المدرجة داخل صفحات الويب بصيغتها الكاملة؛ إذ يصادف المطور في شيفرة الصفحة روابط مجتزأة مثل /login أو images/diagram.png أو ../about، تفتقر صراحة إلى المخطط واسم المضيف. ومع ذلك لا يرسل المتصفح طلبا بعنوان ناقص أبدا، لأنه يحتاج حتما إلى مضيف يفتح الاتصال معه ومسار يطلبه. وتسمى هذه الصيغة المجتزأة المرجع النسبي أو الرابط النسبي (relative reference)، في حين يسمى الرابط المكتمل الرابط المطلق (absolute URL)، ويتكفل المتصفح تلقائيا بتحويل النسبي إلى مطلق قبل إرسال أي طلب عبر الشبكة.
ويتمم المتصفح أجزاء الرابط النسبي بالاستناد إلى عنوان الصفحة الحالية التي احتوت عليه، وهو ما يعرف برابط الأساس (base URL). وتتبع عملية التحويل قواعد دقيقة بحسب استهلال الرابط النسبي؛ فإذا افترضنا أن رابط الأساس هو رابط صفحة المثال https://blog.example.com/articles/url-anatomy:
- الرابط الذي يبدأ بشرطة مائلة، مثل
/login: يرث المخطط والمضيف والمنفذ من رابط الأساس ويستبدل المسار بأكمله، فيصبح العنوان المطلقhttps://blog.example.com/login. - الرابط الذي لا يبدأ بشرطة مائلة، مثل
images/diagram.png: يحسب نسبيا انطلاقا من مسار الصفحة الحالية؛ إذ يستبعد المتصفح آخر مقطع من مسار الأساس ويضع المسار النسبي محله، فيصبح العنوان المطلقhttps://blog.example.com/articles/images/diagram.png. - الرابط الذي يبدأ بالرمز
../، مثل../about: يصعد درجة واحدة إلى المجلد الأعلى بعد استبعاد المقطع الأخير، فيخرج منarticlesليصبح العنوان المطلقhttps://blog.example.com/about. - الرابط الذي يقتصر على استعلام فقط، مثل
?page=3: يبقي المسار كما هو دون أي تغيير ويستبدل به الاستعلام الجديد وحده، فيصبح العنوان المطلقhttps://blog.example.com/articles/url-anatomy?page=3.
وفي هذه الحسابات موضع عملي يقع فيه كثير من المطورين في أخطاء مستعصية: حضور الشرطة المائلة الختامية في نهاية مسار الأساس أو غيابها. فلو كان رابط الأساس ينتهي بشرطة مائلة هكذا https://blog.example.com/articles/، لحافظ المتصفح على المقطع articles واعتبره مجلدا يحتوي المورد، فيتحول الرابط images/diagram.png إلى https://blog.example.com/articles/images/diagram.png. أما لو كان رابط الأساس مجردا من الشرطة الختامية هكذا https://blog.example.com/articles، لعد المتصفح كلمة articles نفسها اسم مورد يستبدل، فيحذفها ويصبح الناتج https://blog.example.com/images/diagram.png. فالقاعدة المتبعة هي أن المقطع الأخير من مسار الأساس يعامل كاسم ملف أو مورد يستبدل ما لم يختم بفاصل الشرطة المائلة. ويفسر هذا السلوك لم قد يفتح مستند بالرابط /articles/ فتعمل صوره وروابطه بسلاسة، ثم تنهار روابط الصور نفسها وتختفي إذا فتح المستند بالرابط /articles من دون شرطة ختامية.
الأصل (origin): المخطط والمضيف والمنفذ ثلاثة لا واحد
يفتح المتصفح في اللحظة الواحدة علامات تبويب لجهات متعددة، وتحمل الصفحة الواحدة عناصر ونصوصا برمجية من نطاقات متباينة. ولكي يحمي المتصفح بيانات كل جهة ويعزل جلسات المستخدمين بأمان، يحتاج إلى وحدة قياس منضبطة: متى يعد موردين تابعين لجهة واحدة موثوقة، ومتى يعدهما جهتين غريبتين يجب الفصل بينهما؟
لا يصلح الرابط الكامل ليكون وحدة قياس؛ لأن كل صفحة أو مسار في الموقع الواحد سيعد حينها جهة غريبة ومعزولة عن بقية صفحات الموقع. ولا يصلح اسم النطاق بمفرده كذلك؛ لأن النطاق الواحد قد يقدم خدماته عبر قناة مكشوفة وأخرى مشفرة، أو قد تشغل خلفه خدمات مستقلة تماما تستمع عند منافذ مختلفة. والوحدة القياسية التي استقرت عليها معايير الويب لحل هذه المعضلة تتكون من ثلاثة عناصر مجتمعة: المخطط، والمضيف، والمنفذ. يسمى هذا الثلاثي المركب الأصل (origin)، ويتطابق أصلان إذا تطابقت عناصرهما الثلاثة بالكامل، في حين يعدان أصلين مختلفين إذا طرأ اختلاف على أي عنصر واحد منها.
وعليه، فإن أصل صفحة المثال https://blog.example.com/articles/url-anatomy هو الثلاثي: المخطط https، والمضيف blog.example.com، والمنفذ 443 (وهو المنفذ الافتراضي المعتمد للمخطط). وتوضح المقارنة التالية كيف يحكم المتصفح على تطابق الأصول:
| الرابط | أهو الأصل نفسه؟ | السبب |
|---|---|---|
https://blog.example.com/login |
نعم | المخطط والمضيف والمنفذ نفسها، والمسار لا يدخل في الحساب |
https://blog.example.com:443/login |
نعم | 443 هو المنفذ الافتراضي لـhttps، فذكره وحذفه سواء |
http://blog.example.com/articles/url-anatomy |
لا | المخطط مختلف |
https://blog.example.com:8443/articles/url-anatomy |
لا | المنفذ مختلف |
https://example.com/articles/url-anatomy |
لا | المضيف مختلف |
ولا يعد إدراج المخطط في معادلة الأصل تشددا شكليا؛ فالمحتوى المنقول عبر بروتوكول http غير المشفر معرض لاعتراض أي وسيط على الشبكة وتبديل بياناته. فلو اعتبر المتصفح http://example.com وhttps://example.com أصلا واحدا، لتمكن مهاجم يتنصت على القناة المكشوفة من حقن نصوص خبيثة تسرق البيانات المحمية داخل جلسة الاتصال المشفر. ولدخول رقم المنفذ مسوغ أمني مماثل: فالبرنامجان اللذان يستمعان عند منفذين مختلفين على الخادم نفسه قد يمثلان تطبيقين مستقلين تماما يتبعان فرق عمل متباينة، ولا مبرر أمنيا يتيح لأحدهما الوصول إلى صلاحيات الآخر أو قراءة بياناته.
ويبرز الأثر العملي للمنفذ بصورة جلية في بيئة التطوير المحلية للمبرمج؛ فالواجهة الأمامية التي تعمل على http://localhost:5173 والخادم الخلفي الذي يستمع على http://localhost:3000 هما أصلان متباينان تماما في نظر المتصفح، على الرغم من تشغيلهما على الحاسوب نفسه وتحت اسم المضيف ذاته.
https://blog.example.com والرابط https://example.com أصلان مختلفان كليا في قواعد الأمان وإن كان أحدهما نطاقا فرعيا تابعا للآخر. وكذلك https://example.com وhttp://example.com أصلان متباعدان أمنيا وإن تطابقت أحرف النطاق بالكامل. فاختلاف أي عنصر مفرد من الثلاثة ينشئ أصلا جديدا مستقلا.أما القيود الصارمة التي يفرضها المتصفح على صفحات أصل معين عند محاولة قراءة موارد أصل آخر، والآلية التي يأذن بها الخادم بتجاوز هذه القيود عبر سياسة مشاركة الموارد عبر الأصول (Cross-Origin Resource Sharing, CORS)، فلها درس تفصيلي مخصص في هذه الدورة يبني مباشرة على هذا الأساس.
عنوان يحمل هوية المطلوب كاملة
يحمل الرابط إذن كل ما يلزم لتحديد المطلوب داخل سياق الرسالة ذاتها، وهو ما ينسجم انسجاما تاما مع السمة الجوهرية لبروتوكول HTTP بوصفه بروتوكولا لا يحفظ الحالة (stateless). ويتجلى عمق هذا التصميم عند مقارنته ببروتوكول يحفظ الحالة مثل بروتوكول نقل الملفات (File Transfer Protocol, FTP)؛ إذ يرسل العميل في FTP أمرا أوليا يغير به المجلد النشط على الخادم، ثم يرسل أمرا تاليا يطلب به اسم ملف مجرد، فيعتمد تفسير الطلب الثاني كليا على حالة الجلسة التي تأسست في الطلب الأول. أما في بروتوكول HTTP فلا توجد ذاكرة بروتوكولية يبني عليها الخادم تفسيره؛ لذا يتحتم على كل طلب مستقل أن يحمل بطاقة تعريف مكتملة المعالم لما يريده العميل، والرابط هو الوعاء الذي يحمل هذه الهوية كاملة: أية جهة مقصودة، وأي مورد مطلوب لديها، وبأية معاملات تفصيلية. ولهذا السبب بالذات، يكفي تبديل حرف مفرد في المسار أو في الاستعلام ليتحول الطلب برمته إلى طلب لمورد مختلف تماما.
اختبر فهمك
ثمانية أسئلة قصيرة تغطي أفكار الدرس. اختر إجابة ثم اضغط «تحقق» لترى إن كانت صحيحة ولماذا. وفي آخر الاختبار تظهر نتيجتك، ومع كل سؤال أخطأت فيه زر يعيدك إلى القسم الذي يشرحه.
https://example.com/p/a%2Fb?q=1#top، أي جزء لا يصل إلى الخادم أبدا؟q=1example.com/p/a%2Fb#top# عن الرابط قبل إرسال الطلب، ويستعمله وحده للانتقال إلى موضع داخل الصفحة. أما المسار والاستعلام فيصلان في هدف الطلب، والمضيف في ترويسة Host.https؟https://example.com/Articles وhttps://example.com/articleshttps://BLOG.example.com/articles وhttps://blog.example.com/articleshttps://example.com/search?q=http وhttps://example.com/search?q=urlhttps://example.com/p/a/b وhttps://example.com/p/a%2Fb/p/a%2Fb؟p ثم مقطع نصه a/bp وa وbp/a/b%2F خرجت من دورها البنيوي فصارت جزءا من نص المقطع. ولا يفصل بين المقاطع إلا الشرطتان غير المرمزتين، ولذلك يتكون المسار من p ثم a/b.https://docs.example.com/guide/intro ورد رابط نسبي نصه ../api/auth. ما العنوان الذي يطلبه المتصفح؟https://docs.example.com/guide/api/authhttps://docs.example.com/guide/intro/api/authhttps://api/authhttps://docs.example.com/api/authintro لأنه اسم مورد لا مجلد، ثم يصعد ../ مستوى فيخرج من guide، ثم يضيف api/auth.https://shop.example.com:8443/cart وhttps://shop.example.com/cart من أصل واحد؟/cart واحد في الرابطينhttps://blog.example.com/articles؟http://blog.example.com/articleshttps://example.com/articleshttps://blog.example.com:443/loginhttps://blog.example.com:8443/articleshttps، فذكره وحذفه سواء، والمسار المختلف لا يغير الأصل. أما الخيارات الأخرى فيختلف في كل منها جزء واحد من الثلاثة: المخطط، أو المضيف، أو المنفذ.