26 مارس 2025·8 دقيقة
ويب تيم برنرز-لي: العناوين (URLs)، HTTP، HTML ولماذا تهم
تعلم كيف جمع تيم برنرز-لي بين URL وHTTP وHTML لتشكيل الشبكة العالمية—ولماذا هذه الأفكار البسيطة لا تزال تدعم التطبيقات وواجهات البرمجة الحديثة.
تعلم كيف جمع تيم برنرز-لي بين URL وHTTP وHTML لتشكيل الشبكة العالمية—ولماذا هذه الأفكار البسيطة لا تزال تدعم التطبيقات وواجهات البرمجة الحديثة.
الشبكة العالمية (غالباً تُدعى «الويب») هي طريقة لنشر والوصول إلى المعلومات باستخدام الروابط. إنها النظام الذي يمكّنك من النقر من صفحة إلى أخرى، فتح صفحة منتج من نتيجة بحث، أو مشاركة رابط يعمل على أي كمبيوتر أو هاتف تقريباً.
في جوهره، الويب يعمل بفضل ثلاثية عملية:
لا تحتاج أن تكون مبرمجاً لتشعر بتأثيرها: في كل مرة تلصق رابطاً، تحمل صفحةً، أو تنقر زر يأخذك إلى مكان آخر، فأنت تعتمد على URL + HTTP + HTML.
الناس غالباً يستخدمون "الويب" و"الإنترنت" بالتبادل، لكنهما مختلفان:
البريد الإلكتروني، الألعاب عبر الإنترنت، وكثير من تطبيقات المحادثة تستخدم الإنترنت دون أن تكون "الويب" بالمعنى الدقيق.
حتى التجارب الحديثة—تطبيقات الصفحة الواحدة، تطبيقات الجوال، وواجهات برمجة التطبيقات—لا تزال تعتمد بقوة على هذه الأساسيات. قد تُخفي التفاصيل، لكنها تستمر في استخدام الـ URLs لتحديد الموارد، HTTP لتبادل الطلبات والاستجابات، وغالباً HTML للتمهيد لما تراه في المتصفح.
لم يحاول تيم برنرز-لي اختراع "الإنترنت". في 1989، أثناء عمله في سيرن، كان يتركز على إحباط عملي: المعلومات المهمة كانت موجودة، لكنها مبعثرة عبر أنظمة غير متوافقة، مخزنة بصيغ مختلفة، ومن الصعب العثور عليها لاحقاً.
الباحثون والفرق والإدارات استخدموا حواسيب وبرمجيات مختلفة. حتى عندما كان لدى مجموعتين «نفس» نوع المستند، قد يخزنهما كل منهما في مكان مختلف، يسميانه باسم مختلف، أو يحتاجان برنامجاً خاصاً لفتحه. المشاركة كانت غالباً تعني إرسال ملفات، تكرار نسخ، وفقدان تتبّع النسخة الأحدث.
كانت الفكرة الأساسية لبرنرز-لي أن يُسمح لأي شخص بنشر مستند على حاسوبه، ثم يتيح للآخرين الوصول إليه بطريقة متسقة—دون الحاجة لمعرفة نوع الجهاز، نظام التشغيل، أو بنية المجلدات الداخلية.
ذلك تطلّب أن تعمل عدة أشياء معاً:
الاختراق لم يكن ميزة واحدة—بل قرار الحفاظ على النظام صغيراً وعالمياً. إذا كانت القواعد بسيطة بما فيه الكفاية، فبإمكان حواسيب ومنظمات مختلفة تنفيذها والتواصل مع بعضها.
ولهذا السبب كانت المعايير المفتوحة مهمة منذ البداية: كان الويب بحاجة لقواعد مشتركة وعامة حتى يشارك فيه العديد من الأنظمة المستقلة. هذا التركيز على المعايير المشتركة—بدل اعتماد سلسلة أدوات بائع واحد—جعل انتشار الويب سريعاً وممكناً لمتصفحات وخوادم جديدة أن تعمل مع المحتوى الموجود.
إذا حاولت يوماً "مشاركة ملف" على محرك شبكة مكتبي فوضوي، فقد رأيت المشكلة الأساسية للشبكات: تسمية الأشياء باستمرار صعبة. الحواسيب المختلفة تخزن المعلومات في أماكن مختلفة، تُعاد تنظيم المجلدات، وقد يتشارك مستندان نفس الاسم. بدون نظام تسمية مشترك، لا يمكنك القول بثقة "احصل على ذلك الشيء هناك".
عالجت عناوين URL هذا للويب بتوفير عنوان عالمي يمكن نسخه ولصقه للمورد.
إليك مثالاً قد تعرفه:
https://www.example.com:443/products/shoes?color=black&size=42#reviews
ما يعنيه كل جزء (ببساطة):
يمكن أن يحدد URL أي شيء يمكن للخادم إرجاعه: صفحة HTML، صورة، PDF، ملف قابل للتحميل، أو حتى نقطة نهاية API يستخدمها تطبيق.
على سبيل المثال:
/images/logo.png (صورة)/docs/terms.pdf (مستند)/api/orders/123 (بيانات لتطبيق)الناس كثيراً ما تستخدم هذه الكلمات بالتبادل:
عملياً، التفكير بـ “URL = عنوان” يغطي حوالي 95% مما تحتاج معرفته.
HTTP هو أسلوب المحادثة الأساسي في الويب. الفكرة بسيطة: متصفحك يطلب شيئاً، والخادم يرد بما لديه (أو يشرح لماذا لا يستطيع).
عندما تكتب عنوان URL أو تنقر رابطاً، يرسل متصفحك طلب HTTP إلى خادم. الطلب يشبه ملاحظة تقول: "أريد هذا المورد بالتحديد".
ثم يرسل الخادم استجابة HTTP. الاستجابة هي الحزمة التي تحتوي النتيجة: المحتوى الذي طلبته (مثل صفحة)، أو رسالة تشرح حصول شيء آخر.
طلبات HTTP تتضمن طريقة، وهي نوع الإجراء الذي تقوم به.
عادةً لا يغيّر GET شيئاً على الخادم؛ هو للقراءة. يُستخدم POST عندما ترسل معلومات للمعالجة.
كل استجابة تتضمن رمز حالة—فكّر به كنتيجة التسليم.
الطلبات والاستجابات تتضمن أيضاً رؤوس، وهي مثل تسميات: "هذا من أنا"، "هذا ما أقبل"، أو "هكذا يجب التعامل مع هذا المحتوى".
واحدة من أكثر التسميات فائدة هي Content-Type، مثل text/html لصفحة الويب أو application/json للبيانات. تخبر هذه المتصفح بما في الداخل حتى يعرضه بشكل صحيح.
HTML (HyperText Markup Language) هي الصيغة المستخدمة لوصف هيكلة صفحة الويب—ما هو المحتوى وكيفية تنظيمه. فكر بها كمستند مع تسميات: "هذا عنوان"، "هذا فقرة"، "هذا رابط"، "هذا حقل نموذج".
يستخدم HTML وسوم لوضع تعيينات على المحتوى. الوسم عادةً له نسخة فتح وإغلاق، ويغلف المحتوى الذي يصفه.
العناوين والفقرات تمنح الصفحة شكلاً. يخبر العنوان الناس والمتصفحات: "هذا عنوان قسم مهم". تقول الفقرة: "هذا نص المحتوى".
الروابط والصور موصوفة أيضاً في HTML. وسم الصورة يشير إلى ملف صورة (مورد)، بينما وسم الرابط يشير إلى URL آخر.
الـ "HT" في HTML—hypertext—هي الفكرة الكبيرة التي جعلت الويب مختلفاً عن الأنظمة السابقة. بدلاً من التنقل عبر القوائم أو مجلدات الملفات أو أوامر خاصة، يمكنك القفز مباشرة من وثيقة إلى أخرى باستخدام روابط قابلة للنقر مضمنة في النص.
هذا التغيير يبدو بسيطاً، لكنه قوي: المعرفة تصبح مترابطة. يمكن لصفحة أن تشير للمصادر، مواضيع ذات صلة، تعاريف، وخطوات لاحقة فوراً—دون الحاجة للعودة إلى فهرس مركزي في كل مرة.
إليك كيف يبدو رابط أساسي:
<a href="/blog/how-http-works">Read more about HTTP</a>
بلغة بسيطة: "اعرض الكلمات Read more about HTTP وعند النقر خذ القارئ إلى الصفحة في /blog/how-http-works."
HTML ليست فقط لنشر المستندات. يمكنها أيضاً وصف مدخلات مثل حقول النص، مربعات الاختيار، والأزرار. هذه العناصر تتيح للصفحة جمع معلومات (مثل تسجيل الدخول، البحث، أو الخروج) وإرسالها إلى خادم.
من السهل الخلط بينها، لكنها تؤدي وظائف مختلفة:
حتى مع تعقّد تطبيقات الويب، يظل HTML نقطة الانطلاق: طريقة مشتركة وقابلة للقراءة لوصف ما تحتويه الصفحة—وأين تقود بعد ذلك.
عندما تزور موقعاً، متصفحك يقوم في الأساس بمهمتين: إيجاد الحاسوب الصحيح للتحدث إليه، وطلب الملف المناسب.
الـ URL (مثل https://example.com/page) هو عنوان الصفحة. يتضمن اسم مضيف (example.com) وغالباً مسار (/page).
الحواسيب على الإنترنت تتحدث باستخدام عناوين رقمية تُدعى عناوين IP. DNS (نظام أسماء النطاقات) يشبه دليل الهاتف الذي يربط example.com بعنوان IP.
هذا البحث عادةً سريع—وأحياناً يُتجاوز لأن الإجابة محفوظة من زيارة سابقة.
الآن يفتح المتصفح اتصالاً بالخادم عند ذلك العنوان IP. إذا بدأ الـ URL بـ https://، يُنشئ المتصفح أيضاً اتصالاً مشفّراً حتى لا يستطيع الآخرون قراءة ما يُرسل بسهولة.
HTTP هو "لغة الطلب والاستجابة" للويب. يرسل المتصفح طلب HTTP مثل: "أرجو إعطائي /page."
يرد الخادم باستجابة HTTP تتضمن حالة (مثل "OK" أو "Not Found") والمحتوى.
غالباً ما يكون ذلك المحتوى HTML. HTML هو صيغة بسيطة تصف بنية الصفحة—عناوين، فقرات، روابط، والمزيد.
أثناء قراءة المتصفح للـ HTML، قد يكتشف أنه يحتاج أيضاً إلى ملفات أخرى (CSS للتصميم، JavaScript للتفاعل، صور، خطوط). ثم يكرر نفس نمط الطلب/الاستجابة لكلٍ منها.
لتسريع الأمور، المتصفحات تحتفظ بـ ذاكرة مؤقتة—نسخة محفوظة من الملفات التي تم تنزيلها سابقاً. إذا لم يتغير شيء، يمكن للمتصفح إعادة استخدام تلك النسخة بدلاً من تنزيلها مرة أخرى.
قائمة فحص سريعة (التدفق):
عندما يقول الناس "الويب"، غالباً يقصدون تجربة سلسة: تنقر رابطاً وتظهر صفحة. تحت السطح، هي علاقة بسيطة بين ثلاث أفكار: خوادم، متصفحات، وموارد.
الخادم هو حاسوب (أو مجموعة حواسيب) متصل بالإنترنت يستضيف الموارد عند عناوين URL. إذا كان الـ URL عنواناً، فالخادم هو المكان الذي يستقبل الزوار عند ذلك العنوان ويقرر ماذا يرسل ردّاً.
ما يرسله الخادم قد يكون صفحة ويب، ملف، أو بيانات. نقطة الأساس أن الخادم مُعدّ للرد على طلبات لعناوين URL محددة.
المتصفح هو برنامج (مثل Chrome، Safari، أو Firefox) الذي يجلب الموارد من الخوادم وي يعرضها بطريقة مفهومة للإنسان.
عندما تدخل URL أو تنقر رابطاً، المتصفح:
المورد هو أي شيء يمكن للويب تحديده وتسليمه عند URL. أمثلة شائعة:
هذا النموذج نفسه لا يقتصر على المتصفحات. يمكن لتطبيق جوال أيضاً طلب URL—عادةً نقطة نهاية API—ويتلقى بيانات ليعرضها في واجهته الخاصة. تبقى الأدوار نفسها: التطبيق كـ "عميل"، والخادم كمستضيف، واستجابة الـ API كمورد.
كانت صفحات الويب المبكرة تعرض المعلومات فقط. النماذج هي ما يجعل الويب يجمع المعلومات—تحوّل الصفحة إلى محادثة ذهاباً وإياباً.
نموذج HTML هو مجموعة منظمة من الحقول (مثل مربعات النص، مربعات الاختيار، والأزرار) إضافةً لتعليماتين رئيسيتين:
action)method، غالباً GET أو POST)عند النقر على "إرسال"، يجهّز المتصفح ما كتبته ويرسله باستخدام HTTP إلى الخادم عند ذلك الـ URL. هذا هو الجسر بين "مستند به حقول" و"تطبيق يعالج الإدخال".
بشكل عام:
فمثلاً يمكن أن يبدو البحث كـ /search?q=shoes (GET)، بينما عملية الدفع قد تُرسل تفاصيل الطلب عبر POST إلى /checkout.
على جهة الخادم، برنامج يستقبل طلب HTTP، يقرأ القيم المرسلة، ويقرر الإجراء التالي:
ثم يرد الخادم—غالباً بصفحة HTML جديدة ("شكراً"), رسالة خطأ، أو إعادة توجيه إلى URL آخر.
إذا تضمن النموذج أي شيء حساس—كلمات مرور، عناوين، تفاصيل دفع—فـ HTTPS أمر ضروري. يمنع الآخرين على الشبكة من قراءة أو تغيير ما يُرسل بين متصفحك والموقع. بدون HTTPS، حتى نموذج تسجيل دخول بسيط يمكن أن يكشف المستخدمين.
التطبيقات الحديثة على الويب ليست مجرد صفحات. معظمها هو ويب زائد كود: صفحة HTML تحميل JavaScript وCSS، ثم يستخدم هذا الكود لتحديث ما ترى دون إعادة تحميل الصفحة بأكملها باستمرار.
حتى عندما يبدو التطبيق كبرنامج أصلي (تغذية متجددة بلا نهاية، تحديثات لحظية، سحب وإفلات)، فإنه ما زال يعتمد على نفس اللبنات الثلاث التي قدّمها تيم برنرز-لي.
الـ URL ليس فقط لـ "صفحة". إنه عنوان لأي مورد: منتج، ملف تعريف مستخدم، استعلام بحث، صورة، أو نقطة نهاية "إرسال رسالة". تطبيقات جيدة تستخدم URLs لجعل المحتوى قابلاً للمشاركة، الحفظ، والربط—سلوك أساسي في الويب.
خلف الكواليس، التطبيقات ترسل طلبات HTTP وتستقبل استجابات HTTP، تماما مثل المواقع الكلاسيكية. القواعد نفسها تنطبق سواء جلبت صفحة HTML أو بيانات لجزء من الشاشة:
معظم التطبيقات الحديثة تتحدث إلى APIs: عناوين URL تُرجع بيانات—غالباً JSON—عبر HTTP.
على سبيل المثال:
HTML ما زال مهماً لأنه غالباً نقطة الانطلاق (وأحياناً الملاذ). وبشكل أوسع، الويب هو منصة للتكامل: إذا اتفقت الأنظمة على URLs وHTTP، يمكنها الاتصال—بغض النظر عمن بنى كل منها.
طريقة عملية لرؤية هذه اللبنات قيد العمل هي بناء شيء صغير—مثلاً واجهة React تتحدث إلى API JSON ولها عناوين قابلة للمشاركة للشاشات الأساسية. أدوات مثل Koder.ai تمشي بنفس النموذج: تصف التطبيق في محادثة، فتنشئ لك حزمة ويب قياسية (React في الواجهة، Go + PostgreSQL في الخلفية)، لذلك ما زلت تعمل مع URLs حقيقية، نقاط نهاية HTTP، وHTML يتم تسليمه من المتصفح—فقط مع إعداد يدوي أقل بكثير.
الويب يعمل على نطاق عالمي لأنه مبني على معايير مشتركة—"قواعد الطريق" عامة تسمح للأنظمة المختلفة بالتواصل بثقة. متصفح من شركة يمكنه طلب صفحة من خادم تديره شركة أخرى، مستضاف في أي مكان، مكتوب بأي لغة برمجة، لأنهم اتفقوا على الأساسيات مثل URLs، HTTP، وHTML.
بدون معايير، كل موقع سيحتاج تطبيقاً مخصصاً لعرضه، وكل شبكة سيكون لها طريقة خاصة لإرسال الطلبات. التقييس يحل أسئلة بسيطة لكنها حاسمة:
عندما تكون هذه القواعد متسقة، يصبح الويب "مزج ومواءمة": أي متصفح متوافق + أي خادم متوافق = يعملان معاً.
المدهش أن المعايير يمكن تحسينها بينما تبقى الأساسيات قابلة للتعرّف. HTTP تحرك من نسخ مبكرة إلى HTTP/1.1، ثم إلى HTTP/2 وHTTP/3، مضيفة أداء وكفاءة أفضل. ومع ذلك، الفكرة الأساسية تبقى: العميل يطلب URL، الخادم يرد برمز حالة، رؤوس، وجسم.
HTML أيضاً نمت—من مستندات بسيطة إلى دلالات أغنى ووسائط مدمجة—مع الحفاظ على مفهوم الصفحات والروابط.
جزء كبير من صمود الويب يأتي من تفضيل قوي للتوافق الخلفي. المتصفحات الجديدة تحاول عرض الصفحات القديمة؛ الخوادم الجديدة لا تزال تفهم طلبات HTTP القديمة. هذا يعني أن المحتوى والروابط يمكن أن تعيش لسنوات—وغالباً لعقود.
إذا أردت أن يظل موقعك أو تطبيقك صالحاً مع الزمن، اعتمد على تصميم قائم على المعايير: استخدم عناوين URL حقيقية لحالات قابلة للمشاركة، اتبع قواعد HTTP للتخزين المؤقت وأكواد الحالة، واكتب HTML صالحاً قبل إضافة طبقات إضافية. المعايير ليست تقييداً—إنها ما يجعل عملك قابل للنقل والاعتماد ومهيأ للمستقبل.
حتى لو استخدمت الويب يومياً، بعض المصطلحات تختلط كثيراً إلى حد أنها قد تعرقل التحري عن الأخطاء أو التخطيط أو حتى المحادثات البسيطة. هنا خلطات شائعة—وأسرع طريقة لتصحيحها.
مفهوم خاطئ: الإنترنت والويب هما نفس الشيء.
تصحيح سريع: الإنترنت هو الشبكة العالمية (الكابلات، الموجهات، الاتصالات). الويب هو خدمة تعمل فوقها، مبنية من URLs، HTTP، وHTML.
مفهوم خاطئ: "عنواني هو example.com."
تصحيح سريع: example.com هو نطاق. الـ URL يمكن أن يتضمن تفاصيل أكثر—مثل المسار والاستعلام—مثل:
https://example.com/pricing (مسار محدد)https://example.com/search?q=shoes (مسار مع استعلام)تلك الأجزاء الإضافية قد تغيّر ما يعيده الخادم.
مفهوم خاطئ: HTML وHTTP قابلان للاستبدال.
تصحيح سريع: HTTP هي "محادثة التسليم" (طلب واستجابة). HTML هي إحدى الحزم الممكنة التي تُسلَّم—غالباً تلك التي تصف صفحة وروابطها. HTTP يمكن أن يرسل أيضاً JSON، صور، PDF، أو فيديو.
مفهوم خاطئ: أي خطأ يعني "الموقع معطل"، وإعادة التوجيه دائماً سيئة.
تصحيح سريع: أكواد الحالة هي إشارات:
مفهوم خاطئ: كل URL يجب أن يفتح صفحة قابلة للقراءة البشرية.
تصحيح سريع: يمكن أن يشير URL إلى بيانات (/api/orders)، ملف (/report.pdf)، أو نقطة إجراء لإرسال نموذج.
مفهوم خاطئ: إذا كان HTTPS، الموقع آمن وصادق.
تصحيح سريع: HTTPS يشفر الاتصال ويساعد في التأكد من أنك تتواصل مع النطاق المقصود—لكنه لا يضمن أن العمل التجاري موثوق. عليك تقييم المصدر والمحتوى والسياق بنفسك.
الفكرة الأساسية لتيم برنرز-لي كانت مفاجئة ببساطتها: ربط المستندات (ولاحقاً التطبيقات) باستخدام مخطط عنونة مشترك، وطريقة مشتركة لطلب البيانات، وصيغة مشتركة لعرضها والربط بينها.
URL هو العنوان. يخبرك ما تريد وأين يعيش (وغالباً كيف تصل إليه).
HTTP هو المحادثة. مجموعة القواعد التي يستخدمها المتصفح والخادم لطلب شيء والرد به (أكواد الحالة، الرؤوس، التخزين المؤقت، والمزيد).
HTML هي صيغة الصفحة. ما يقرأه المتصفح لعرض المحتوى—والمكان الأساسي الذي تربط فيه الصفحات موارد أخرى.
فكّر في الويب كحلقة بسيطة من ثلاث خطوات:
بعد أن تتقن هذه الحلقة، التفاصيل الحديثة (الكوكيز، APIs، تطبيقات الصفحة الواحدة، CDNs) تصبح أسهل للفهم: إنها عادةً تحسينات لتسمية، طلب، أو عرض.
إذا أردت التعمق دون الدخول للتفاصيل التقنية المفرطة:
فهم هذه الأساسيات يعود عليك سريعاً: ستكون أفضل في تقييم أدوات الويب ("هل هذا يعتمد على URLs وHTTP القياسي؟"), التواصل مع المطورين، واستكشاف مشكلات يومية مثل الروابط المكسورة، مفاجآت التخزين المؤقت، أو أخطاء "404 مقابل 500".
الإنترنت هو الشبكة العالمية (الموجهات، الكابلات، توجيه الـ IP) التي تربط الحواسيب. الويب هو خدمة تعمل فوقها: موارد محددة بـ URLs تُنقل عبر HTTP وغالباً ما تُعرض كـ HTML.
العديد من الأشياء تستخدم الإنترنت دون أن تكون “الويب”، مثل البريد الإلكتروني وبعض ألعاب الشبكة وأنظمة الدردشة.
فكّر في URL كعنوان دقيق لمورد. يمكن أن يشير إلى صفحة HTML، صورة، PDF، أو نقطة نهاية API.
عنوان URL النموذجي يتضمن:
https) — كيف تصل إليهالـ نطاق (domain) مثل example.com هو اسم المضيف. الـ URL يمكن أن يتضمن تفاصيل إضافية—كالمسار والاستعلام—التي تغيّر ما تحصل عليه بالفعل.
على سبيل المثال:
https://example.com/pricinghttps://example.com/search?q=shoesالـ fragment (الجزء بعد #) يتعامل معه المتصفح ولا يُرسل إلى الخادم ضمن طلب HTTP.
استخداماته الشائعة:
#reviews)إذا غيّرت الجزء بعد فقط، فعادةً لن يُجرى إعادة تحميل كاملة للصفحة.
HTTP هي قواعد محادثة الطلب والاستجابة بين العميل (المتصفح/التطبيق) والخادم.
عملياً:
استخدم GET عندما تريد استرجاع شيء (للقراءة فقط بالنية)، مثل تحميل صفحة أو جلب بيانات.
استخدم POST عندما ترسل بيانات لتُعالَج—كإنشاء حساب، نشر تعليق، أو بدء عملية دفع.
نصيحة عملية: إذا كان الإجراء يجب أن يكون قابلاً للاشتراك/المشاركة (مثل بحث)، فغالباً GET مناسب؛ وإذا غيّر حالة الخادم، فـ POST هو المعتاد.
أكواد الحالة تلخّص نتيجة الطلب:
عند الاستكشاف، غالباً ما يشير إلى رابط خاطئ أو صفحة محذوفة؛ أما فغالباً ما يعني وجود خطأ برمجي أو عطل في الخادم.
يحتاج المتصفح إلى عنوان IP للاتصال بالخادم. DNS هو النظام الذي يترجم اسم الإنسان (مثل example.com) إلى عنوان IP.
إذا فشل الموقع أحياناً في "التحلّل"، فـ DNS عادةً يكون مشتبهًا به—خاصة إذا فشل على شبكة/جهاز واحد لكنه يعمل على آخر.
التخزين المؤقت (caching) يعني أن المتصفح يحتفظ بنسخ من الموارد التي تم تنزيلها سابقاً بحيث تكون الزيارات المتكررة أسرع.
الآثار العملية:
الخوادم تتحكم بكثير من سلوك التخزين عبر رؤوس HTTP (مثل مدة التخزين وإعادة التحقق).
HTTPS يشفر الحركة ويُساعد في التأكد من أنك متصل بالنطاق المقصود، مما يحمي بيانات تسجيل الدخول والنماذج والمعلومات الحساسة أثناء النقل.
إنه لا يضمن أن الموقع جدير بالثقة أو أن العمل التجاري موثوق. لا بد من تقييم:
example.com) — أي خادم/products/shoes) — أي مورد?color=black) — معلمات إضافية#reviews) — موقع داخل الصفحة (يتعامل معه المتصفح محلياً)#