ما هو الفرق بين HTTP و HTTPS؟ ولماذا تحتاج SSL؟

في المقال السابق رأيتَ كيف يحوّل «نظام أسماء النطاقات DNS» اسم الموقع إلى عنوان IP. صار متصفّحك يعرف أين الخادم، وفتح معه قناة. لكن بأيّ «لغة» سيطلب الصفحة، وبأيّ لغة يردّ الخادم؟ هذه اللغة هي HTTP، بروتوكول نقل النصّ التشعّبيّ، وهي قواعد المحادثة التي يقوم عليها الويب كلّه.

سأشرح في هذا المقال كيف تجري هذه المحادثة: شكل الطلب والردّ، والأفعال التي تطلب بها، ورموز الحالة التي يجيبك بها الخادم، والترويسات التي تحمل التفاصيل، وكيف يتذكّرك موقع على بروتوكول «لا يتذكّر»، ثم كيف تطوّر البروتوكول ليصير أسرع، وما الذي تضيفه «S» في HTTPS.

نموذج الطلب والاستجابة

HTTP بروتوكول بسيط في جوهره: العميل (متصفّحك) يرسل طلبا (Request)، والخادم يرسل استجابة (Response). لا حوار مفتوح، بل سؤال وجواب. تجري هذه المحادثة فوق قناة TCP التي مرّت بك في مسار الطلب عبر الإنترنت، على المنفذ 80 لـHTTP أو 443 لـHTTPS.^[1]

والرسالة في الاتجاهين نصّ مقروء (في إصداراته الأولى على الأقلّ)، وهذا جزء من سرّ انتشار الويب: أيّ متصفّح يفهم أيّ خادم، لأن الجميع يتكلّم القواعد نفسها التي تحدّدها مواصفة HTTP.^[4]

تشريح الطلب والاستجابة

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

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0

والاستجابة لها البنية نفسها مقلوبة: سطر أول فيه إصدار البروتوكول ورمز الحالة (هل نجح الطلب)، ثم ترويسات، ثم جسم الردّ (الصفحة نفسها مثلًا):

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1024

<!DOCTYPE html> ...

متى فهمتَ هذين القالبين، فهمتَ HTTP، وفي الشكل 1 تراهما متجاورين. كلّ ما تبقّى تفصيل في الفعل، والرمز، والترويسات.

شكل 1

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

وصفحة واحدة ليست طلبا واحدا. حين تفتح موقعا، يجلب المتصفّح ملفّ HTML أولا، ثم يقرأه فيجد إحالات إلى عشرات الموارد (تنسيقات، ونصوص برمجية، وصور، وخطوط)، فيرسل لكلّ منها طلب HTTP مستقلّا. فما تراه صفحة واحدة هو في الحقيقة عشرات المحادثات القصيرة مع الخادم، تجري متوازية في أجزاء من الثانية. ويمكنك أن ترى هذا بعينك: افتح «أدوات المطوّر» في متصفّحك (المفتاح F12)، ثمّ تبويب «الشبكة» (Network)، وأعد تحميل الصفحة، فتظهر لك كل طلباتها ورموز حالتها وترويساتها وأحجامها وأزمنتها. لا شيء أصدق من النظر إلى البروتوكول وهو يعمل.

الأفعال: ماذا تطلب؟ (Methods)

الفعل (Method) يحدّد نيّة الطلب. أشهرها:^[2]

GET: اجلب موردا (صفحة، صورة)، وهو الفعل الأشيع، وكل تصفّح عاديّ سلسلة من طلبات GET.
POST: أرسل بيانات إلى الخادم لينشئ شيئا أو يعالجه، كإرسال نموذج تسجيل أو تعليق.
PUT: استبدل موردا كاملا بنسخة جديدة.
PATCH: عدّل جزءا من مورد دون استبداله كلّه.
DELETE: احذف موردا.
HEAD: اطلب ترويسات الردّ فقط دون جسمه، للتحقّق من شيء دون تنزيله.
OPTIONS: اسأل الخادم عن العمليات التي يسمح بها على المورد.

ولهذه الأفعال خاصّيتان مهمّتان عمليا. الفعل «الآمن» (Safe) لا يغيّر شيئا على الخادم، بل يقرأ فقط (مثل GET وHEAD)، فيأمن المتصفّح أن يسبق تحميله. والفعل «المتكرّر بأمان» (Idempotent) يعطي النتيجة نفسها مهما كرّرتَه (GET وPUT وDELETE)، وهذا ما يسمح بإعادة المحاولة عند انقطاع الشبكة دون خوف من تكرار الأثر. أما POST فليس آمنا ولا متكرّرا بأمان، ولهذا يحذّرك المتصفّح أحيانا قبل إعادة إرسال نموذج.^[2] وحين يحمل الطلب جسما (كما في POST وPUT)، تصف ترويسة Content-Type نوع ذلك الجسم: نموذجا مُرمَّزا، أو ملفّا، أو بيانات JSON؛ فيقرأ الخادم هذه الترويسة ليعرف كيف يفسّر ما أرسلتَه. وتجدر ملاحظة عملية: المتصفّح في التصفّح العاديّ لا يستعمل مباشرةً إلا GET (للروابط) وPOST (للنماذج)؛ أما PUT وDELETE وPATCH فتستعملها غالبًا شيفرة JavaScript والواجهات البرمجية التي يأتي ذكرها في آخر المقال.

رموز الحالة: هل نجح الطلب؟

يبدأ ردّ الخادم برقم من ثلاث خانات يلخّص النتيجة. خانته الأولى تحدّد فئته، وهي خمس:^[3]

1xx إعلامية: ردّ مؤقّت، «استمرّ».
2xx نجاح: تمّ الطلب. أشهرها 200 OK، و201 Created (أُنشئ مورد)، و204 No Content (نجح بلا محتوى يُعاد).
3xx إعادة توجيه: المورد انتقل. 301 (نقل دائم) و302 (مؤقّت) و304 Not Modified (نسختك المخزّنة ما زالت صالحة).
4xx خطأ العميل: العيب في طلبك. 400 (طلب معطوب)، 401 (يلزم تسجيل دخول)، 403 (ممنوع)، 404 (غير موجود)، 429 (طلبات أكثر من اللازم).
5xx خطأ الخادم: طلبك سليم لكنّ الخادم عجز. 500 (خطأ داخليّ)، 502 (ردّ فاسد من خادم وسيط)، 503 (الخدمة غير متاحة، صيانة أو ضغط).

هذه الفئات الخمس تكفيك لتشخيص أيّ مشكلة بسرعة: إن رأيت 4xx فراجِع طلبك أو صلاحيتك، وإن رأيت 5xx فالعطل في الخادم لا فيك.

ولبعض الرموز قصص عملية: يستعمل أصحاب المواقع 301 حين ينقلون صفحة إلى عنوان جديد، ليحوّلوا الزوّار ومحرّكات البحث إليه دون كسر الروابط القديمة. ويردّ الخادم بـ503 أثناء الصيانة، وقد يرفقه بترويسة Retry-After تقترح متى تُعيد المحاولة. ويظهر 429 حين يطلب عميل أكثر مما يسمح به الخادم في فترة قصيرة، وهو شائع مع الواجهات البرمجية المحدودة بحصّة.

طلب جزء من الملفّ: كيف تسحب شريط الفيديو؟

HTTP يجلب الموارد كاملة في الأصل. فكيف تنقر في وسط فيديو طويل فيبدأ من هناك بعد لحظة، دون تنزيل ما قبله؟ الجواب ترويسة اسمها Range: يطلب بها المتصفّح مدى من البايتات لا الملفّ كلّه، مثل «أعطني من البايت 5,000,000 إلى 5,999,999». فإن قبل الخادم كان جوابه 206 Partial Content لا 200. ومعه ترويسة Content-Range تقول أيّ جزء أرسل ومن أصل كم.^[7]

وعلى هذه الترويسة يقوم أمرانِ تستعملهما كثيرًا. الأوّل تقديم الفيديو والصوت: كلّ نقرة على الشريط طلبُ مدى جديد. والثاني استئناف التنزيل المنقطع: يعرف البرنامج كم بايتا وصله، فيطلب ما بعده لا الملفّ من أوّله. وللخادم أن يعلن قدرته على ذلك سلفا بترويسة Accept-Ranges في ردّه، فيعرف البرنامج أنّ الاستئناف متاح قبل أن يجرّبه. وإن لم يدعم الخادم المدَيات ردّ بالملفّ كاملا كأنّك لم تسأل، ولهذا يتعذّر الاستئناف على بعض الخوادم فتبدأ من الصفر.

الترويسات: التفاصيل التي تحمل المحادثة

الترويسات (Headers) أزواج «اسم: قيمة» تُرفَق بالطلب والردّ لتحمل ما لا يتّسع له السطر الأول. في طلبك تخبر Accept الخادمَ بأنواع المحتوى التي تقبلها، وAccept-Language بلغتك المفضّلة، وUser-Agent بنوع متصفّحك، وAuthorization برمز دخولك. وفي الردّ يخبرك Content-Type بنوع ما أُرسِل (صفحة؟ صورة؟ JSON؟)، وContent-Length بحجمه، وCache-Control بمدّة صلاحية تخزينه، وSet-Cookie بكوكي ليثبّت الخادم شيئا في متصفّحك.^[1] وبالترويسات تجري مفاوضة خفية على شكل المحتوى: ترسل Accept-Encoding لتقول إنك تقبل المحتوى مضغوطا (بصِيَغ مثل gzip أو brotli)، فيضغطه الخادم ويوفّر من حجم النقل كثيرًا قبل أن يفكّه متصفّحك. وبها تُضبط أيضًا قواعد «مشاركة الموارد بين المصادر» (CORS) التي تحدّد أيّ المواقع يُسمح لها بطلب موارد موقعك من المتصفّح. فالترويسات ليست تفاصيل ثانوية، بل المكان الذي تُدار فيه أكثر سلوكيات الويب.

هذه الترويسة الأخيرة تقودك إلى سؤال جوهريّ: كيف يتذكّرك الموقع أصلًا؟

بروتوكول بلا ذاكرة: كيف يتذكّرك الموقع إذن؟

HTTP «عديم الحالة» (Stateless): كل طلب مستقلّ تمامًا، والخادم لا يربط طلبك الحاليّ بسابقه، بل يعامل كلّ رسالة كأنها أول مرّة.^[1] هذا تصميم متعمّد يجعل الخوادم بسيطة وقابلة للتوسّع: لأن كل طلب مكتف بذاته، يستطيع أيّ خادم في مزرعة الخوادم أن يعالج أيّ طلب دون أن يعرف ما سبقه، فتُوزَّع ملايين الطلبات على خوادم كثيرة بلا تعقيد. لكنّه يطرح مشكلة: إن كان الخادم لا يتذكّر، فكيف يبقى تسجيل دخولك قائما وأنت تتنقّل بين الصفحات؟

الحلّ أن تُضاف «الحالة» فوق البروتوكول لا داخله. حين تسجّل دخولك، يرسل الخادم في ردّه ترويسة Set-Cookie فيها معرّف صغير، يخزّنه متصفّحك ويعيد إرساله مع كل طلب تال، فيتعرّف عليك الخادم. هذه فكرة الكوكيز والجلسات والرموز (Tokens)، ولها مقال مستقلّ في السلسلة عن الكوكيز والجلسات. المهمّ هنا أن «الذاكرة» ليست في HTTP نفسه، بل حيلة ذكية فوقه.

وللكوكيز أنواع: كوكي «الجلسة» يزول بإغلاق المتصفّح، و«الدائم» يبقى مدّة محدّدة. وقد تتجاوز التطبيقات الحديثة الكوكيز إلى «الرموز» (Tokens مثل JWT) التي يحملها التطبيق ويرسلها في ترويسة Authorization. وأيّا كان الأسلوب، يلزم تأمينه: راية HttpOnly تمنع شيفرة الصفحة من قراءة الكوكي حماية من سرقته، وراية Secure تمنع إرساله إلا عبر HTTPS.

HTTPS: اللغة نفسها داخل غلاف مشفّر

في HTTP العاديّ تسافر الرسالة نصّا مكشوفا، فيقدر أيّ متنصّت على الطريق أن يقرأ ما ترسله أو يعدّله. أما HTTPS فليس بروتوكولا جديدا، بل هو HTTP نفسه يجري داخل طبقة تشفير اسمها TLS، تُعمّي المحادثة وتثبت هوية الخادم.^[1] لهذا صار HTTPS معيار كل موقع جادّ اليوم، وتضع المتصفّحات علامة «غير آمن» على ما يبقى على HTTP. والتشفير لا يحفظ السرّية وحدها، بل يمنع العبث أيضًا: على HTTP يستطيع وسيط في الطريق (كمزوّد خدمة أو شبكةِ مقهى) أن يحقن إعلانا أو يعدّل صفحة قبل وصولها إليك، وHTTPS يكشف أيّ تبديل فيرفضه المتصفّح.

وملاحظة: زالت أيقونة «القفل الأخضر» القديمة؛ صارت المتصفّحات تكتفي بقفل محايد، أو تحذّر حين يغيب التشفير. القفل لا يعني أن الموقع «صادق» أو «حسن النيّة»، بل يعني أن الاتصال مشفّر وأن هوية النطاق موثّقة فحسب. وكيف تجري هذه المصافحة، وما الشهادة التي تثبت الهوية، موضوع المقال التالي عن بروتوكول SSL/TLS.

ترويسات الأمان

وفوق التشفير، تتيح ترويسات خاصّة للموقع أن يشدّد حمايته بسطور قليلة. ترويسة HSTS تأمر المتصفّح ألّا يتّصل بالموقع إلا عبر HTTPS أبدًا، فتحمي كلّ زيارة بعد الأولى. أمّا الزيارة الأولى فلا تحميها ترويسة لم تصل بعد، وهي ثغرة معروفة باسمها في المواصفة.^[6] وسدّها يحتاج إلى ما يبلغ المتصفّح قبل أن يتّصل: قائمة مُدمَجة في المتصفّح تُسمّى قائمة HSTS المُحمَّلة مسبقا، وقد فكّكتُها في مقال معرّف الموارد الموحّد. وترويسة CSP («سياسة أمان المحتوى») تحدّد المصادر المسموح للصفحة تحميل النصوص والصور منها، فتكبح هجمات حقن النصوص (XSS). وثمّة أصغر منها مثل X-Content-Type-Options التي تمنع المتصفّح من «تخمين» أنواع الملفّات تخمينا قد يكون خطيرا. هذه الترويسات من أرخص ما يرفع أمان موقعك، وكثير من المواقع يغفلها.

تطوّر البروتوكول: من HTTP/1.1 إلى HTTP/3

بقيت قواعد HTTP (الأفعال والرموز والترويسات) ثابتة عبر إصداراته، لكنّ طريقة نقلها على الشبكة تطوّرت سعيا للسرعة:^[1]

HTTP/1.0: كان يفتح قناة TCP جديدة لكل طلب، ويغلقها بعده. بطيء مع الصفحات الكثيرة الموارد.
HTTP/1.1: أضاف «القناة الدائمة» (Keep-Alive)، فصارت طلبات كثيرة تمرّ على قناة واحدة دون إعادة فتحها في كل مرّة.
HTTP/2: حوّل الرسائل إلى صيغة ثنائية، وأتاح «التزامن» (Multiplexing): عشرات الطلبات والردود تتداخل على القناة الواحدة دون أن ينتظر بعضها بعضا.
HTTP/3: نقل HTTP من TCP إلى بروتوكول QUIC فوق UDP، فدمج مصافحة الاتصال والتشفير في خطوة واحدة، وعالج مشكلة تعطّل حزمة واحدة لكل القناة. هو الأحدث، وتدعمه المتصفّحات والمواقع الكبرى اليوم.^[5]

والدافع وراء HTTP/2 وHTTP/3 مشكلة اسمها «انسداد رأس الطابور» (Head-of-Line Blocking): في القناة الواحدة، كان بطء ردّ واحد أو ضياع حزمة يوقف كلّ ما خلفه في الصفّ ولو كان جاهزا. عالج HTTP/2 ذلك على مستوى الطلبات بالتزامن، فلم يَعُد طلب بطيء يحجب البقية. ثمّ عالجه HTTP/3 على مستوى النقل نفسه بالانتقال إلى QUIC، فصار ضياع حزمة لا يجمّد سائر القناة. هذا هو جوهر «السرعة» التي يُنسب الفضل فيها إلى هذه الأجيال. وكلّها تخدم هدفا واحدا: تقليل كلفة البداية. ففتح كل اتصال جديد يكلّف رحلاتِ ذهاب وإياب (مصافحة TCP، ومعها مصافحة TLS في HTTPS)، فكلّما أُعيد استعمال القناة نفسها أو دُمجت المصافحات، اقترب زمن وصول الصفحة من حدّه الأدنى الذي تفرضه المسافة وحدها.

ويبقى سؤال عمليّ: من أين يعرف متصفّحك أنّ الخادم يتكلّم HTTP/3 أصلًا؟ الطريقة الأولى ترويسة في الردّ اسمها Alt-Svc يقول بها الخادم: «أتكلّم h3 أيضًا، فتعال إليّ به في المرّة القادمة». ولاحظ العلّة نفسها التي مرّت بك في ترويسة HSTS عند ترويسات الأمان: الترويسة لا تصل إلّا بعد اتصال قد جرى بالفعل، فالمرّة الأولى تمضي على الإصدار القديم دائمًا.

والحلّ من الشكل نفسه أيضًا: أن يُنقَل الخبر خارج القناة، إلى DNS. فسجلّ حديث اسمه HTTPS يحمل في نطاقك أيّ البروتوكولات يتكلّمها خادمك، فيقرؤه المتصفّح مع استعلام الاسم قبل أن يفتح أيّ اتصال، فيبدأ بـHTTP/3 من أوّل خطوة.^[8] وهو سجلّ من سجلّات DNS، وقد فكّكتُ أنواعها الشائعة في المقال السابق. ومثال على أنّ الطبقات تتعاون: يحلّ DNS مشكلة لا يستطيع HTTP أن يحلّها بنفسه. ويمكنك أن ترى أيّ إصدار استُعمل فعلًا: في لسان «الشبكة» بأدوات المطوّر أضِف عمود Protocol، فيظهر بجانب كلّ طلب h2 أو h3 أو http/1.1.

التخزين المؤقّت عبر HTTP

ولـHTTP دور ثان غير النقل: فهو يدير متى يُعاد التنزيل ومتى يُكتفى بنسخة محفوظة. بترويسة Cache-Control يحدّد الخادم مدّة صلاحية المورد، فلا يطلبه المتصفّح ثانية قبل انتهائها. وبترويسة ETag يعطي الخادم «بصمة» للنسخة، فإن عاد المتصفّح يسأل عنها وكانت لم تتغيّر، ردّ الخادم بـ304 Not Modified دون إعادة إرسال المحتوى، فيوفّر وقتا ونقلا.^[1] هذه الآلية جزء من سبب سرعة الويب، ولها تفصيل في مقال التخزين المؤقّت على الويب. وإن أردتَ تجاوز النسخة المخزّنة ورؤية أحدث ما عند الخادم، يطلب «التحديث القسريّ» (بالضغط Ctrl+Shift+R) نسخة طازجة متجاهلا الكاش.

على أنّ 304 ليس مجانا. فالمتصفّح لم يصل إليه إلّا بعد أن سأل الخادم وانتظر جوابه، أي دفع رحلة ذهاب وإياب كاملة ولم يوفّر إلّا حجم المحتوى. أمّا النسخة التي لم تنتهِ صلاحيتها بعد فلا تكلّف شيئا على الشبكة: يقرؤها المتصفّح من قرصه ولا يسأل أحدا. ولهذا يفرّق المطوّرون بين «صالحة» و«يجب التحقّق منها»: الأولى صفر رحلات، والثانية رحلة واحدة مقابل حجم موفّر.

أخطاء شائعة تراها في الطريق

متى عرفتَ قواعد HTTP، صارت أعطاله مفهومة لا غامضة. من أشيعها «المحتوى المختلط» (Mixed Content): صفحة آمنة على HTTPS تحاول تحميل صورة أو نصّ برمجيّ عبر HTTP، فيمنعه المتصفّح حماية لك. ومنها أخطاء CORS التي تظهر في وحدة تحكّم المطوّر حين يطلب موقع موردا من نطاق آخر لم يأذن له بذلك في ترويساته. ومنها صفحات 404 التي تعني أن المسار في عنوانك لا يقابله مورد على الخادم، إما لخطأ في الرابط وإما لأن الصفحة حُذفت أو نُقلت. وحدة «الشبكة» في أدوات المطوّر هي أسرع طريق لتشخيص أيّ منها: انظر إلى رمز الحالة والترويسات تَرَ السبب.

أبعد من المتصفّح: HTTP أساس الـAPIs

قد تظنّ HTTP خاصّا بتصفّح الصفحات، لكنّه صار لغة تخاطب البرامج بعضها مع بعض. حين يجلب تطبيق على هاتفك الطقسَ أو أسعار العملات، فهو يرسل طلب HTTP إلى «واجهة برمجية» (API) ويتلقّى ردّا، غالبًا بصيغة JSON لا صفحة HTML، كهذا:

GET /api/weather?city=damascus HTTP/1.1

200 OK
Content-Type: application/json

{ "city": "Damascus", "temp": 24, "unit": "C" }

القالب نفسه الذي مرّ بك (فعل، ومسار، ورمز حالة، وترويسات، وجسم)، لكنّ الجسم بيانات يقرؤها برنامج لا صفحة يعرضها متصفّح. وأسلوب REST الشائع في بناء هذه الواجهات يستعمل أفعال HTTP بمعناها المباشر: GET لقراءة بيانات، وPOST لإنشائها، وPUT لتعديلها، وDELETE لحذفها. ورموز الحالة تحمل معناها نفسه: 200 نجاح، و201 أُنشئ، و404 غير موجود، و401 يلزم تسجيل دخول. هذه الوحدة هي ما يجعل المطوّر يتعلّم HTTP مرّة ويستعمله في كل مكان: من تصفّح صفحة بسيطة إلى ربط نظامين ضخمين. فما تعلّمتَه هنا ليس عن المتصفّح وحده، بل عن الطريقة التي تتكلّم بها برمجيّات العالم على الإنترنت.

شاهد المحادثة بنفسك

هذه المحادثة كلّها تجري أمامك في كل صفحة تفتحها، وتستطيع مشاهدتها مباشرةً. افتح أيّ موقع، ثمّ افتح «أدوات المطوّر» في متصفّحك (بمفتاح F12) واختر لسان «Network» (الشبكة)، وأعد تحميل الصفحة. سترى كلّ طلب يرسله المتصفّح: مستند HTML، وكلّ ملفّ يتبعه، وبجانب كلّ فعلُه (GET غالبًا) ورمز حالته (200 أو 404…) وحجمه وزمنه. وانقر أيّ طلب لترى ترويساته كاملة، طلبا وردّا. لا شيء يرسّخ هذا المقال مثل أن ترى عشرات الطلبات تنهمر في ثوان لتبني صفحة واحدة.

من الطلب إلى الأمان

HTTP لغة بسيطة في قلبها: طلب وردّ، فعل ورمز، وترويسات تحمل التفاصيل. وعلى هذه البساطة بُني الويب كلّه، ثمّ بُنيت فوقها الجلسات والواجهات البرمجية وأجيال أسرع من النقل. متى قرأتَ سطر الطلب وفهمتَ رمز الحالة، فهمتَ ما يجري في كل نقرة.

بقي سؤال واحد: مرّ بك أنّ «S» في HTTPS هي طبقة TLS التي تشفّر المحادثة وتثبت هوية الخادم، لكن كيف تتمّ هذه المصافحة فعلًا، وما هذه «الشهادة» التي يقدّمها الخادم ليثبت أنه هو؟ هذا موضوع المقال التالي: «بروتوكول SSL/TLS: قفل الإنترنت السرّي».

المصادر

MDN Web Docs: An overview of HTTP. نموذج الطلب/الاستجابة، الترويسات، انعدام الحالة، HTTPS فوق TLS، التخزين المؤقّت، وإصدارات HTTP.
MDN Web Docs: HTTP request methods. الأفعال، وخاصّيتا «الآمن» (Safe) و«المتكرّر بأمان» (Idempotent).
MDN Web Docs: HTTP response status codes. الفئات الخمس وأهمّ الرموز.
IETF: RFC 9110: HTTP Semantics. المواصفة الرسمية لدلالات HTTP (الأفعال، الرموز، الترويسات).
IETF: RFC 9114: HTTP/3. نقل HTTP فوق بروتوكول QUIC.
IETF: RFC 6797: الإلزام الصارم بالنقل الآمن (HSTS)، القسمان 12.3 و14.6. ثغرة الاتصال الأوّل، والقائمة المُحمَّلة مسبقا التي وُضعت لسدّها.
IETF: RFC 9110: دلالات HTTP، القسم 14. ترويسة Range، والرمز 206، وترويسة Content-Range.
IETF: RFC 9460: ربط الخدمة عبر DNS (سجلّات SVCB وHTTPS). سجلّ HTTPS يعلن البروتوكولات المدعومة قبل أوّل اتصال.

HTTP وHTTPS: كيف يطلب متصفّحك صفحةً ويردّ الخادم