HTTP

الموسوعة الحرة

بروتوكول نقل النص التشعبي ( HTTP ) هو بروتوكول طبقة التطبيقات ضمن مجموعة بروتوكولات الإنترنت لأنظمة المعلومات الموزعة والتعاونية والوسائط المتعددة . [ 1 ] يُعدّ HTTP أساس نقل البيانات في شبكة الويب العالمية ، حيث تتضمن مستندات النص التشعبي روابط تشعبية إلى موارد أخرى يمكن للمستخدم الوصول إليها بسهولة، على سبيل المثال بالنقر بالماوس أو بالنقر على الشاشة في متصفح الويب .

بروتوكول HTTP هو بروتوكول طلب واستجابة في نموذج العميل والخادم . تبدأ المعاملة بإرسال العميل طلبًا إلى الخادم، ويحاول الخادم تلبية الطلب ويعيد استجابة إلى العميل تصف حالة الطلب، وقد تحتوي اختياريًا على مورد مطلوب مثل مستند HTML أو محتوى آخر.

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

صُمم بروتوكول HTTP للسماح لعناصر الشبكة الوسيطة بتحسين أو تمكين الاتصالات بين العملاء والخوادم. غالبًا ما تستفيد مواقع الويب ذات الزيارات العالية من خوادم التخزين المؤقت للويب التي تُقدم المحتوى نيابةً عن الخوادم الرئيسية لتحسين سرعة الاستجابة. تُخزن متصفحات الويب موارد الويب التي تم الوصول إليها مسبقًا وتُعيد استخدامها، كلما أمكن، لتقليل حركة مرور الشبكة. يمكن لخوادم وكيل HTTP على حدود الشبكات الخاصة تسهيل الاتصال للعملاء الذين لا يملكون عنوانًا قابلًا للتوجيه عالميًا، وذلك عن طريق إعادة توجيه الرسائل مع الخوادم الخارجية.

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

يتم تحديد موقع مورد الويب بواسطة محدد موقع الموارد الموحد (URL)، باستخدام مخططات معرف الموارد الموحد (URI) http و https . يتم ترميز URIs كروابط تشعبية في مستندات HTML ، وذلك لتكوين مستندات نصية تشعبية مترابطة . [ 2 ]

الإصدارات

خضع البروتوكول للمراجعة والتعديل على مرّ الزمن. يُشار إلى كل إصدار بالرمز HTTP/#، حيث يُمثّل # رقم الإصدار. تتناول هذه المقالة جوانب جميع الإصدارات، مع التركيز بشكل أساسي على HTTP/0.9 وHTTP/1.0 وHTTP/1.1. وتُغطّي مقالات أخرى HTTP/2 و HTTP/3 بالتفصيل.

إصدارقدَّمحالة
0.91991مهجور
1.01996مهجور
1.11997معيار
22015معيار
32022معيار

في بروتوكول HTTP/1.0، يتم إنشاء اتصال TCP منفصل مع نفس الخادم لكل طلب مورد. [ 3 ] : §1.3

في بروتوكول HTTP/1.1، يُمكن إعادة استخدام اتصال TCP لإجراء طلبات متعددة للموارد (مثل صفحات HTML، والإطارات، والصور، والبرامج النصية ، وأوراق الأنماط ، إلخ). [ 4 ] : ​​§9.1، 9.3. وبالتالي، تتميز اتصالات HTTP/1.1 بانخفاض زمن الاستجابة ، حيث يُمثل إنشاء اتصالات TCP عبئًا كبيرًا، خاصةً في ظروف الازدحام الشديد. [ 5 ]

تتيح التحسينات المضافة مع بروتوكول HTTP/2 تقليل زمن الاستجابة، وفي معظم الحالات، سرعات أعلى من اتصالات HTTP/1.1. يدعم HTTP/2 ما يلي:

  • تمثيل ثنائي مضغوط للبيانات الوصفية (رؤوس HTTP) بدلاً من التمثيل النصي، بحيث تتطلب الرؤوس مساحة أقل بكثير؛
  • اتصال واحد TCP/IP (عادة ما يكون مشفرًا ) لكل نطاق خادم يتم الوصول إليه بدلاً من 2 إلى 8 اتصالات TCP/IP؛
  • قناة واحدة أو أكثر ثنائية الاتجاه لكل اتصال TCP/IP حيث يتم تقسيم طلبات واستجابات HTTP وإرسالها في حزم صغيرة لحل مشكلة HOLB ( حجب رأس الطابور ) تقريبًا؛ [ ملاحظة 1 ]
  • خاصية الدفع التي تسمح لتطبيق الخادم بإرسال البيانات إلى العملاء كلما توفرت بيانات جديدة (دون إجبار العملاء على طلب بيانات جديدة من الخادم بشكل دوري باستخدام أساليب الاستقصاء ). [ 6 ] : §2

يستخدم بروتوكول HTTP/3 بروتوكولي النقل QUIC وUDP بدلاً من TCP. ويُستخدم فقط طبقة IP (التي يعتمد عليها UDP، مثل TCP). يُحسّن هذا قليلاً متوسط ​​سرعة الاتصالات ويتجنب مشكلة ازدحام اتصالات TCP التي قد تُعيق أو تُبطئ تدفق البيانات لجميع تدفقاتها مؤقتًا (وهو شكل آخر من أشكال " حجب رأس الطابور ").

يستخدم

يدعم بروتوكول HTTP/2 ما يصل إلى 71% من مواقع الويب [ 7 ] [ 8 ] (34.1% منها تدعم HTTP/2، و36.9% تدعم HTTP/3 مع التوافق مع الإصدارات السابقة)، كما يدعمه جميع متصفحات الويب تقريبًا (أكثر من 98% من المستخدمين) [ 9 ] . ويدعمه أيضًا خوادم الويب الرئيسية عبر بروتوكول أمان طبقة النقل (TLS) باستخدام امتداد بروتوكول التفاوض على طبقة التطبيق (ALPN) [ 10 ] حيث يُشترط استخدام TLS 1.2 أو أحدث [ 6 ] .

يُستخدم بروتوكول HTTP/3 في 36.9% من مواقع الويب [ 11 ] ، وهو مدعوم من معظم متصفحات الويب، أي أنه مدعوم (جزئيًا على الأقل) من قِبل 97% من المستخدمين. [ 12 ] يستخدم HTTP/3 بروتوكول QUIC بدلاً من TCP كبروتوكول نقل أساسي. ومثل HTTP/2، لا يُلغي الإصدارات الرئيسية السابقة من البروتوكول. في عام 2019، أُضيف دعم HTTP/3 لأول مرة إلى Cloudflare و Chrome [ 13 ] [ 14 ] ، كما تم تفعيله في Firefox . [ 15 ] يتميز HTTP/3 بزمن استجابة أقل لصفحات الويب في الواقع العملي، ويُحمّل بشكل أسرع من HTTP/2، وفي بعض الحالات أسرع بثلاث مرات من HTTP/1.1، الذي لا يزال البروتوكول الوحيد المُفعّل في أغلب الأحيان. [ 16 ]

يستخدم أكثر من 85% من مواقع الويب بروتوكول HTTPS ، وهو النسخة الآمنة من بروتوكول HTTP. [ 17 ]

تكنولوجيا

طبقة النقل

يفترض بروتوكول HTTP وجود بروتوكول طبقة نقل أساسي موثوق . [ 18 ] : §3.3 كان بروتوكول التحكم بالنقل (TCP) هو البروتوكول الأساسي القياسي قبل HTTP/3 . يستخدم HTTP/3 طبقة نقل مختلفة تُسمى QUIC ، والتي توفر موثوقية أعلى من بروتوكول بيانات المستخدم (UDP) غير الموثوق. تم تعديل HTTP/1.1 والإصدارات الأقدم لاستخدامها عبر UDP غير الموثوق في حالات البث المتعدد والبث الأحادي ، لتشكيل HTTPMU وHTTPU. تُستخدم هذه البروتوكولات في UPnP وبروتوكول اكتشاف الخدمة البسيط (SSDP)، وهما بروتوكولان يعملان عادةً على شبكة محلية .

تبادل البيانات

بروتوكول HTTP هو بروتوكول غير مُحتفظ بالحالة على مستوى التطبيق، ويتطلب اتصالاً موثوقاً به لنقل البيانات بين العميل والخادم. [ 19 ] في تطبيقات HTTP، تُستخدم اتصالات TCP/IP عبر منافذ معروفة (عادةً المنفذ 80 إذا كان الاتصال غير مُشفّر، أو المنفذ 443 إذا كان مُشفّراً، انظر أيضاً قائمة أرقام منافذ TCP وUDP ). [ 18 ] : §4.2.1، 4.2.2. في HTTP/2، يُستخدم اتصال TCP/IP بالإضافة إلى قنوات بروتوكول متعددة. أما في HTTP/3، فيُستخدم بروتوكول نقل التطبيقات QUIC عبر UDP.

رسائل الطلب والاستجابة عبر الاتصالات

يتم تبادل البيانات عبر سلسلة من رسائل الطلب والاستجابة، والتي يتم تبادلها عبر اتصال نقل طبقة الجلسة . [ 19 ] يحاول عميل HTTP في البداية إنشاء اتصال، حقيقي أو افتراضي، مع الخادم. يقبل خادم HTTP المُستمع على المنفذ الاتصال، ثم ينتظر رسالة طلب العميل. يرسل العميل رسالة طلب HTTP الخاصة به. عند استلام الطلب، يُرسل الخادم رسالة استجابة HTTP، والتي تتضمن رأسًا أو أكثر، بالإضافة إلى نص الرسالة إذا لزم الأمر. عادةً ما يكون نص رسالة الاستجابة هو المورد المطلوب، على الرغم من أنه قد يتم أيضًا إرجاع رسالة خطأ أو معلومات أخرى. في أي وقت ولأسباب عديدة، يمكن للعميل أو الخادم إغلاق الاتصال. عادةً ما يتم الإعلان عن إغلاق الاتصال بواسطة رأس HTTP واحد أو أكثر في آخر طلب أو استجابة. [ 4 ] : ​​§9.1

اتصالات مستمرة

في بروتوكول HTTP/0.9، يتم إغلاق اتصال TCP/IP دائمًا بعد إرسال استجابة الخادم، لذلك فهو ليس مستمرًا أبدًا.

في بروتوكول HTTP/1.0، يجب على الخادم دائمًا إغلاق اتصال TCP/IP بعد إرسال الاستجابة. [ 3 ] [ ملاحظة 2 ]

في بروتوكول HTTP/1.1، تم تقديم آلية إبقاء الاتصال مفتوحًا رسميًا، مما يسمح بإعادة استخدام الاتصال لأكثر من طلب/استجابة. تُقلل هذه الاتصالات المستمرة زمن استجابة الطلب بشكل ملحوظ، لأن العميل لا يحتاج إلى إعادة التفاوض على اتصال المصافحة الثلاثية TCP بعد إرسال الطلب الأول. ومن الآثار الجانبية الإيجابية الأخرى، أن الاتصال يصبح أسرع مع مرور الوقت بفضل آلية بدء التشغيل البطيء في TCP .

أضاف بروتوكول HTTP/1.1 ميزة تجميع الطلبات (Pipelining) لتقليل زمن الاستجابة عند استخدام الاتصالات المستمرة، وذلك بالسماح للعملاء بإرسال طلبات متعددة قبل انتظار كل استجابة. لم يُعتبر هذا التحسين آمنًا تمامًا، إذ لم تتعامل بعض خوادم الويب والعديد من خوادم البروكسي ، وخاصةً خوادم البروكسي الشفافة الموجودة على الإنترنت/ الشبكات الداخلية بين العملاء والخوادم، مع الطلبات المجمعة بشكل صحيح (إذ كانت تعالج الطلب الأول فقط وتتجاهل البقية، أو تغلق الاتصال عند وجود بيانات إضافية بعد الطلب الأول، أو حتى تُعيد بعض خوادم البروكسي الاستجابات بترتيب خاطئ، إلخ). ونتيجةً لذلك، اقتصرت إمكانية تجميع طلبات HEAD وبعض طلبات GET (أي طلبات الملفات الحقيقية، وبالتالي عناوين URL التي لا تحتوي على سلسلة استعلام، إلخ) بشكل آمن ومتكرر . بعد سنوات من المعاناة مع المشاكل الناجمة عن تفعيل تجميع الطلبات، تم تعطيل هذه الميزة أولًا ثم إزالتها من معظم المتصفحات. كما أُزيلت ميزة تجميع الطلبات أيضًا مع الإعلان عن اعتماد بروتوكول HTTP/2.

قام بروتوكول HTTP/2 بتوسيع استخدام الاتصالات المستمرة من خلال تعدد إرسال العديد من الطلبات/الاستجابات المتزامنة عبر اتصال TCP/IP واحد.

لا يستخدم بروتوكول HTTP/3 اتصالات TCP/IP بل يستخدم QUIC + UDP.

تحسينات استرجاع المحتوى

في بروتوكول HTTP/0.9، كان يتم إرسال المورد المطلوب دائمًا بكامله.

أضاف بروتوكول HTTP/1.0 رؤوسًا لإدارة الموارد المخزنة مؤقتًا بواسطة العميل من أجل السماح بطلبات GET المشروطة.

  • يجب على الخادم إرجاع المحتوى الكامل للمورد المطلوب فقط إذا لم يكن وقت تعديله الأخير معروفًا من قبل العميل أو إذا تغير منذ آخر استجابة كاملة لطلب GET.
  • تمت إضافة رأسية Content-Encodingلتحديد ما إذا كان المحتوى المُعاد مضغوطًا أم لا .
  • إذا لم يكن حجم المحتوى معروفًا مسبقًا (أي لأنه يُنشأ ديناميكيًا)، فلن يتم تضمين الترويسة Content-Length. سيفترض العميل أن النقل قد اكتمل عند إغلاق الاتصال، ولكن الإغلاق المبكر سيترك العميل بمحتوى جزئي دون أن يدرك ذلك.

تم تقديم بروتوكول HTTP/1.1، وتوفر الإصدارات اللاحقة ما يلي:

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

جلسة تقديم الطلبات

باعتباره بروتوكولًا لا يحتفظ بالحالة ، لا يتطلب بروتوكول HTTP من خادم الويب الاحتفاظ بمعلومات أو حالة كل مستخدم طوال مدة الطلبات المتعددة. إذا احتاج تطبيق ويب إلى جلسة تطبيق ، فإنه يُنفذها عبر ملفات تعريف الارتباط الخاصة ببروتوكول HTTP ، [ 21 ] أو متغيرات مخفية في نموذج ويب ، أو آلية أخرى.

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

المصادقة

يوفر بروتوكول HTTP العديد من أنظمة المصادقة مثل مصادقة الوصول الأساسية ومصادقة الوصول الملخص والتي تعمل من خلال آلية التحدي والاستجابة حيث يقوم الخادم بتحديد وإصدار تحدٍ قبل تقديم المحتوى المطلوب.

يوفر بروتوكول HTTP إطارًا عامًا للتحكم في الوصول والمصادقة، من خلال مجموعة قابلة للتوسيع من مخططات المصادقة القائمة على التحدي والاستجابة، والتي يمكن للخادم استخدامها للتحقق من طلب العميل، ويمكن للعميل استخدامها لتقديم معلومات المصادقة. [ 18 ]

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

تتضمن مواصفات مصادقة HTTP نطاقات توفر بنيةً خاصة بالتنفيذ لتقسيم الموارد المشتركة لعنوان URI جذري معين . يتم دمج سلسلة قيمة النطاق، إن وجدت، مع عنوان URI الجذري المتعارف عليه لتشكيل مكون مساحة الحماية للتحدي. وهذا يسمح للخادم فعليًا بتحديد نطاقات مصادقة منفصلة ضمن عنوان URI جذري واحد. [ 1 ]

اتصال مشفر

الطريقة الأكثر شيوعًا لإنشاء اتصال HTTP مشفر هي HTTPS . [ 22 ] توجد طريقتان أخريان لإنشاء اتصال HTTP مشفر: بروتوكول نقل النص التشعبي الآمن (STP) ، واستخدام ترويسة HTTP/1.1 Upgrade لتحديد الترقية إلى TLS. مع ذلك، يكاد دعم المتصفحات لهاتين الطريقتين يكون معدومًا. [ 23 ] [ 24 ] [ 25 ]

تنسيق الرسالة

طلب HTTP/1.1 تم إجراؤه باستخدام telnet. تظهر أجزاء العملية بألوان مختلفة: الطلب باللون الأحمر، ورأس الاستجابة باللون الأرجواني، وجسم الاستجابة باللون الأخضر.

يصف هذا القسم الرسائل الخاصة ببروتوكول HTTP/1.1. أما الإصدارات اللاحقة، HTTP/2 [ 26 ] و HTTP/3 ، فتستخدم بروتوكولًا ثنائيًا ، حيث تُشفّر الرؤوس في إطار واحد HEADERSأو صفر أو أكثر CONTINUATIONباستخدام HPACK [ 27 ] (HTTP/2) أو QPACK (HTTP/3)، وكلاهما يوفر ضغطًا فعالًا للرؤوس. كما استُبدل سطر الطلب أو الاستجابة من HTTP/1 بعدة حقول رؤوس وهمية، يبدأ كل منها بنقطتين رأسيتين ( ::).

على أعلى مستوى، تتكون الرسالة من رأس متبوع بجسم.

يتكون رأس الطلب من أسطر نصية ASCII ، وينتهي كل سطر بتسلسل إرجاع السطر وتغذية السطر . يكون تخطيط رأس الطلب ورأس الاستجابة كما يلي:

خط البداية
بيانات منظمة تختلف باختلاف الطلب والاستجابة.
حقول العنوان
صفر أو أكثر من أسطر حقول الرأس (واحد على الأقل لـ HTTP/1.1)؛ انظر أدناه.
سطر فارغ
يشير إلى نهاية العنوان.

جسم

يتكون نص الرسالة من بيانات بأي تنسيق، وليس بالضرورة بتنسيق ASCII. يجب أن يتطابق التنسيق مع التنسيق المحدد في Content-Typeحقل الترويسة إن وُجد. نص الرسالة اختياري، أي يمكن تركه فارغًا.

كيان

قبل بروتوكول HTTP/2، كان مصطلح "الكيان" يُستخدم للإشارة إلى محتوى الطلب بالإضافة إلى حقول الترويسة التي تصفه. وبالتحديد، لم تكن جميع الترويسات تُعتبر جزءًا من الكيان. وكان مصطلح " ترويسة الكيان" يُشير إلى الترويسة التي تُعتبر جزءًا من الكيان، وأحيانًا كان يُطلق على محتوى الطلب اسم " محتوى الكيان" . أما في الوثائق الحديثة، فيُستخدم مصطلحا "المحتوى" و "الترويسة" دون استخدام مصطلح "الكيان" .

حقل العنوان

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

يُنسق سطر حقل العنوان على شكل زوج من الاسم والقيمة، يفصل بينهما نقطتان رأسيتان. لا يُسمح بوجود مسافات بيضاء حول الاسم، ولكن تُتجاهل المسافات البيضاء في بداية ونهاية جزء القيمة. على عكس اسم الدالة الذي يجب أن يتطابق تمامًا (حساس لحالة الأحرف)، [ 28 ] يُطابق اسم حقل العنوان مع تجاهل حالة الأحرف، على الرغم من أنه غالبًا ما يُعرض بحرف كبير في بداية كل كلمة. [ 29 ] على سبيل المثال، فيما يلي حقول عنوان لـ Hostو Accept-Language.

المضيف: www.example.com لغة القبول: الإنجليزية

لا تحدد المعايير حجم حقل الترويسة أو عدد الحقول في الرسالة. مع ذلك، تفرض معظم الخوادم والعملاء وبرامج البروكسي قيودًا لأسباب عملية وأمنية. على سبيل المثال، يحد خادم Apache 2.3 افتراضيًا حجم كل حقل إلى 8190 بايت، ويمكن ألا يتجاوز عدد حقول الترويسة في الطلب الواحد 100 حقل. [ 30 ]

على الرغم من أن RFC 7230 قد تم إهمالها في الماضي ، [ 31 ] ، كان من الممكن تقسيم الأسطر الطويلة إلى أسطر متعددة مع سطر متابعة يبدأ بمسافة أو حرف جدولة .

طلب

يُرسل العميل طلبًا إلى الخادم. يتضمن سطر البداية اسم الطريقة، ومعرّف الموارد الموحد (URI) للطلب، وإصدار البروتوكول، مع وجود مسافة واحدة بين كل حقل. [ 32 ] يحدد سطر بداية الطلب التالي الطريقة GET، ومعرّف الموارد الموحد (URI) /customer/123، وإصدار البروتوكول HTTP/1.1:

طلب GET /customer/123 HTTP/1/1.1

تسمح حقول رأس الطلب للعميل بتمرير معلومات إضافية تتجاوز سطر الطلب، وتعمل كمعدّلات للطلب (على غرار معلمات الإجراء). وهي توفر معلومات حول العميل، أو حول المورد المستهدف، أو حول المعالجة المتوقعة للطلب. في بروتوكول HTTP/1.1، جميع حقول الرأس Hostاختيارية باستثناء حقل معين.

يتم قبول سطر الطلب الذي يحتوي فقط على اسم المسار من قبل الخوادم للحفاظ على التوافق مع عملاء HTTP قبل مواصفات HTTP/1.0 في RFC 1945. [ 33 ] 

مورد

يُصمّم البروتوكول المعاملات بحيث تعمل على الموارد. ويعتمد تعريف المورد، سواءً أكان بيانات موجودة مسبقًا أم بيانات يتم إنشاؤها ديناميكيًا، على آلية عمل الخادم. غالبًا ما يكون المورد عبارة عن ملف أو ناتج برنامج تنفيذي يعمل على الخادم.

طريقة

يُحدد الطلب طريقة (تُسمى أحيانًا بشكل غير رسمي فعلًا ) لتصنيف الإجراء المطلوب تنفيذه على مورد. حددت مواصفات HTTP/1.0 [ 3 ] : §8 طرق GET وHEAD وPOST، بالإضافة إلى إدراج طرق PUT وDELETE وLINK وUNLINK ضمن الطرق الإضافية. مع ذلك، أضافت مواصفات HTTP/1.1 [ 34 ] : §9 خمس طرق جديدة: PUT وDELETE وCONNECT وOPTIONS وTRACE. يمكن لأي عميل استخدام أي طريقة، ويمكن تهيئة الخادم لدعم أي مجموعة من الطرق. إذا كانت طريقة ما غير معروفة لعميل وسيط، فسيتم التعامل معها على أنها طريقة غير آمنة وغير قابلة للتكرار . لا يوجد حد لعدد الطرق التي يمكن تعريفها، مما يسمح بتحديد طرق مستقبلية دون التأثير على البنية التحتية الحالية. على سبيل المثال، حدد WebDAV سبع طرق جديدة، وحدد RFC 5789 طريقة PATCH . يشترط على خادم الويب ذي الأغراض العامة تنفيذ طلبات GET وHEAD على الأقل، وتُعتبر جميع الطرق الأخرى اختيارية وفقًا للمواصفات. [ 18 ] : §9.1 

أسماء الطرق حساسة لحالة الأحرف. [ 4 ] : ​​§3 [ 18 ] : §9.1 وهذا على عكس أسماء حقول ترويسة HTTP التي لا تُراعي حالة الأحرف. [ 18 ] : §6.3

يحصل
يُطلب من المستخدم الحصول على تمثيل لمورد. يجب على الخادم استرجاع البيانات فقط ، دون تعديل الحالة. [ 1 ] وللاسترجاع دون إجراء تغييرات، يُفضّل استخدام طلب GET على طلب POST، إذ يُمكن الوصول إليه عبر عنوان URL . وهذا يُتيح حفظ الإشارات المرجعية والمشاركة، ويجعل استجابات GET قابلة للتخزين المؤقت ، مما يُساهم في توفير عرض النطاق الترددي. وقد نشر اتحاد شبكة الويب العالمية (W3C) مبادئ توجيهية بشأن هذا التمييز، حيث جاء فيها: " ينبغي أن يستند تصميم تطبيقات الويب إلى المبادئ المذكورة أعلاه، بالإضافة إلى القيود ذات الصلة." [ 35 ]

رأس
يشبه هذا الطلب طلب GET، إلا أن الاستجابة لا تتضمن بيانات التمثيل في نصها. يُفيد هذا في استرجاع بيانات التمثيل الوصفية من ترويسة الاستجابة، دون الحاجة إلى نقل التمثيل كاملاً. ومن استخداماته التحقق من توفر صفحة ما عبر رمز الحالة، والحصول على حجم ملف عبر حقل الترويسة Content-Length.

بريد
يُستخدم هذا الطلب لمعالجة مورد ما بطريقة ما. على سبيل المثال، يُستخدم لنشر رسالة في منتدى على الإنترنت ، أو الاشتراك في قائمة بريدية ، أو إتمام عملية شراء عبر الإنترنت . [ 18 ] : §9.3.3

يضع
يهدف الطلب إلى إنشاء مورد أو تحديثه بالحالة المحددة في الطلب. ويكمن الفرق بينه وبين طلب POST في أن العميل يُحدد الموقع المستهدف على الخادم. [ 18 ] : §9.3.4

يمسح
الطلب هو حذف مورد.

يتصل
يطلب هذا الطلب من الوسيط إنشاء نفق TCP/IP إلى خادم المصدر المحدد بواسطة هدف الطلب. ويُستخدم غالبًا لتأمين الاتصالات عبر وكيل HTTP واحد أو أكثر باستخدام TLS . [ 18 ] : §9.3.6 [ 36 ] انظر طريقة HTTP CONNECT .

خيارات
يُستخدم هذا الطلب للحصول على تقرير بأساليب HTTP المدعومة لمورد معين. ويمكن استخدامه للتحقق من وظائف خادم الويب عن طريق طلب "*" بدلاً من مورد محدد.

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

رقعة
يهدف الطلب إلى تعديل مورد وفقًا لحالته الجزئية المذكورة في الطلب. وبالمقارنة مع طلب PUT، يمكن لهذا الأسلوب توفير عرض النطاق الترددي عن طريق إرسال جزء فقط من تمثيل المورد بدلاً من إرساله بالكامل. [ 37 ]

استفسار
تطلب هذه الطلبات من الخادم معالجة المحتوى المرفق بطريقة آمنة ومتكررة، ثم الرد بالنتيجة. وهذا مشابه لطلبات POST، ولكن يمكن تكرار طلبات QUERY أو إعادة تشغيلها تلقائيًا دون القلق بشأن التغييرات الجزئية في الحالة. [ 38 ]

خصائص طرق الطلب
طريقةRFCيحتوي الطلب على نص الحمولةيحتوي الرد على نص الحمولةآمنمُكررقابلة للتخزين المؤقت
يحصلRFC 9110 خيارينعمنعمنعمنعم
رأسRFC 9110 خياريلانعمنعمنعم
بريدRFC 9110 نعمنعملالانعم
يضعRFC 9110 نعمنعملانعملا
يمسحRFC 9110 خيارينعملانعملا
يتصلRFC 9110 خيارينعملالالا
خياراتRFC 9110 خيارينعمنعمنعملا
يتعقبRFC 9110 لانعمنعمنعملا
رقعةRFC 5789 نعمنعملالالا
استفسارRFC 10008 نعمنعمنعمنعمنعم
طريقة آمنة

تُعتبر طريقة الطلب آمنة إذا لم يكن للطلب المُستخدم فيها أي تأثير مُراد على الخادم. وتُعرّف الطرق GET وHEAD وOPTIONS وTRACE بأنها آمنة. بعبارة أخرى، الطرق الآمنة مُصممة للقراءة فقط . مع ذلك، قد يكون للطرق الآمنة آثار جانبية غير مرئية للعميل، مثل إضافة معلومات الطلب إلى ملف السجل أو خصم رسوم من حساب إعلاني .

في المقابل، تُعدّ طرق POST وPUT وDELETE وCONNECT وPATCH غير آمنة. فقد تُغيّر حالة الخادم أو تُحدث آثارًا أخرى مثل إرسال بريد إلكتروني . ولذلك، لا تستخدم برامج الزحف على الويب المتوافقة مع معايير الأمان هذه الطرق عادةً؛ بينما تميل بعض البرامج غير المتوافقة إلى إرسال الطلبات دون مراعاة السياق أو العواقب.

على الرغم من الأمان المُفترض لطلبات GET، إلا أن معالجتها من قِبل الخادم غير مقيدة تقنيًا بأي شكل من الأشكال. قد تسمح البرمجة غير الدقيقة أو المتعمدة غير المنتظمة لطلبات GET بإحداث تغييرات جوهرية على الخادم. يُنصح بتجنب ذلك نظرًا للمشاكل التي قد تحدث عند قيام التخزين المؤقت للويب ، ومحركات البحث ، وغيرها من البرامج الآلية بإجراء تغييرات غير مقصودة على الخادم. على سبيل المثال، قد يسمح موقع ويب بحذف مورد عبر عنوان URL مثل https://example.com/article/1234/delete ، والذي، في حال جلبه بشكل عشوائي، حتى باستخدام GET، سيؤدي ببساطة إلى حذف المقالة. [ 39 ] يتطلب موقع ويب مُبرمج بشكل صحيح استخدام طريقة DELETE أو POST لهذا الإجراء، وهو ما لا تقوم به برامج الروبوت غير الضارة.

ومن الأمثلة على ذلك ما حدث عملياً خلال النسخة التجريبية القصيرة الأجل من برنامج Google Web Accelerator ، حيث كان يقوم بجلب عناوين URL عشوائية مسبقاً على الصفحة التي يتصفحها المستخدم، مما أدى إلى تغيير السجلات أو حذفها تلقائياً بشكل جماعي . وقد تم تعليق النسخة التجريبية بعد أسابيع قليلة من إطلاقها الأول، إثر انتقادات واسعة النطاق. [ 40 ]

طريقة التكرار

تُعتبر طريقة الطلب متكررة النتائج إذا كان لعدة طلبات متطابقة باستخدام هذه الطريقة نفس تأثير طلب واحد. تُعرَّف طرق PUT وDELETE، بالإضافة إلى الطرق الآمنة، بأنها متكررة النتائج. الطرق الآمنة متكررة النتائج بشكل بديهي، لأنها مصممة بحيث لا يكون لها أي تأثير على الخادم؛ أما طرق PUT وDELETE، فهي متكررة النتائج لأنه سيتم تجاهل الطلبات المتطابقة المتتالية. على سبيل المثال، قد يُنشئ موقع ويب نقطة نهاية PUT لتعديل عنوان البريد الإلكتروني المُسجَّل للمستخدم. إذا تم تكوين نقطة النهاية هذه بشكل صحيح، فلن يكون لأي طلبات تطلب تغيير عنوان البريد الإلكتروني للمستخدم إلى نفس عنوان البريد الإلكتروني المُسجَّل بالفعل - مثل الطلبات المُكرَّرة بعد طلب ناجح - أي تأثير. وبالمثل، لن يكون لطلب DELETE الخاص بمستخدم معين أي تأثير إذا تم حذف هذا المستخدم بالفعل.

على النقيض من ذلك، فإن طرق POST وCONNECT وPATCH ليست بالضرورة متكررة النتائج، وبالتالي فإن إرسال طلب POST متطابق عدة مرات قد يُغير حالة الخادم أو يُحدث آثارًا أخرى، مثل إرسال رسائل بريد إلكتروني متعددة . في بعض الحالات، يكون هذا التأثير مرغوبًا، ولكن في حالات أخرى قد يحدث عن طريق الخطأ. على سبيل المثال، قد يُرسل المستخدم عن غير قصد عدة طلبات POST بالنقر على زر مرة أخرى إذا لم يتلقَّ تنبيهًا واضحًا بأن النقرة الأولى قيد المعالجة. في حين أن متصفحات الويب قد تُظهر مربعات حوار تنبيهية لتحذير المستخدمين في بعض الحالات التي قد يؤدي فيها إعادة تحميل الصفحة إلى إعادة إرسال طلب POST، فإن الأمر متروك عمومًا لتطبيق الويب للتعامل مع الحالات التي لا ينبغي فيها إرسال طلب POST أكثر من مرة.

لاحظ أن كون دالة ما متكررة التنفيذ أم لا ليس شرطًا مفروضًا من قِبل البروتوكول أو خادم الويب. من الممكن تمامًا كتابة تطبيق ويب حيث يتم (على سبيل المثال) إدخال بيانات في قاعدة البيانات أو أي إجراء آخر غير متكرر التنفيذ عند استخدام طلب GET أو أي طلب آخر. مع ذلك، فإن القيام بذلك خلافًا للتوصيات قد يؤدي إلى عواقب غير مرغوب فيها، إذا افترض برنامج المستخدم أن تكرار الطلب نفسه آمن بينما هو ليس كذلك.

طريقة قابلة للتخزين المؤقت

تُعتبر طريقة الطلب قابلة للتخزين المؤقت إذا كان من الممكن تخزين الاستجابات للطلبات التي تستخدم تلك الطريقة لإعادة استخدامها لاحقًا. وتُعرَّف الطرق GET وHEAD وPOST على أنها قابلة للتخزين المؤقت.

في المقابل، فإن الطرق PUT و DELETE و CONNECT و OPTIONS و TRACE و PATCH غير قابلة للتخزين المؤقت.

إجابة

يرسل الخادم استجابةً إلى العميل. يتكون سطر بداية الاستجابة من إصدار البروتوكول، ورمز الحالة، وعبارة السبب (اختيارية)، وتفصل بين هذه الحقول مسافة واحدة. [ 4 ] : ​​§2.1 يحدد سطر بداية الاستجابة التالي إصدار البروتوكول HTTP/1.1، ورمز الحالة 400، وعبارة السبب Bad Request.

HTTP/1.1 400 طلب غير صالح

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

رمز الحالة

رمز الحالة هو قيمة عددية عشرية مكونة من ثلاثة أرقام، تمثل حالة محاولة الخادم لتلبية طلب العميل. عادةً، يتعامل العميل مع الاستجابة بناءً على رمز الحالة بشكل أساسي، ثم بناءً على حقول رأس الاستجابة بشكل ثانوي. قد لا يفهم العميل كل رمز حالة يُبلغه الخادم، لكن يجب عليه فهم الفئة كما هو موضح بالرقم الأول، والتعامل مع أي رمز غير معروف على أنه مكافئ لرمز x00 لتلك الفئة. الفئات هي كالتالي:

معلومات 1XX
تم استلام الطلب، ويجري استكمال الإجراءات.
2XX ناجح
تم استلام الطلب وفهمه وقبوله بنجاح.
إعادة توجيه 3XX
يلزم اتخاذ إجراءات إضافية لإتمام الطلب.
خطأ من جانب العميل 4XX
لا يمكن تلبية الطلب بسبب مشكلة قد يكون بإمكان العميل التحكم بها.
خطأ في الخادم 5XX
فشل الخادم في تلبية طلب يبدو صحيحاً.

عبارة السبب

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

مثال

يوضح المثال التالي عملية تبادل بيانات HTTP/1.1 لخادم على الموقع www.example.com ، المنفذ 80. يستخدم HTTP/1.0 نفس الرسائل باستثناء بعض الرؤوس المفقودة. أما HTTP/2 وHTTP/3 فيستخدمان نفس آلية تبادل البيانات، ولكن بتمثيلات مختلفة لرؤوس HTTP.

فيما يلي طلب بدون محتوى. يتكون من سطر بداية، وستة حقول رأسية، وسطر فارغ - ينتهي كل منها بتسلسل إرجاع السطر وتغذية السطر . Hostيميز حقل الرأس بين أسماء نطاقات DNS المختلفة التي تشترك في عنوان IP واحد ، مما يسمح بالاستضافة الافتراضية القائمة على الاسم . بينما كان اختياريًا في HTTP/1.0، أصبح إلزاميًا في HTTP/1.1.

طلب GET / HTTP / 1.1 Host : www.example.com User-Agent : Mozilla/5.0 Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Connection : keep-alive

على الرغم من عدم وضوح ذلك في التمثيل أعلاه (بسبب قيود هذه الويكي)، فإن السطر الفارغ في النهاية يؤدي إلى ظهور سلسلتين من فواصل الأسطر. وعند تمثيلها كسلسلة من الأحرف، يُظهر إصدار مختصر من المثال أعلاه هذا الأمر بشكل أوضح مع <CRLF>تمثيل سلسلة فواصل الأسطر: GET / HTTP/1.1<CRLF>Host: www.example.com<CRLF><CRLF>.

في الاستجابة التالية، يُستخدم حقل رأس ETag (علامة الكيان) لتحديد ما إذا كانت النسخة المخزنة مؤقتًا من المورد المطلوب مطابقة للنسخة الحالية من المورد على الخادم. Content-Typeيُحدد حقل الرأس نوع وسائط الإنترنت للبيانات المنقولة بواسطة رسالة HTTP، ويُشير إلى طولها بالبايت. يُعلن خادم الويبContent-Length HTTP/1.1 عن قدرته على الاستجابة لطلبات نطاق بايت من المورد عن طريق تضمين . يُعد هذا مفيدًا إذا كان العميل بحاجة إلى أجزاء مُحددة فقط [ 41 ] من مورد مُرسل من الخادم، وهو ما يُسمى خدمة البايت . عند إرسال ، فهذا يعني أن خادم الويب سيُغلق اتصال TCP فور انتهاء نقل هذه الاستجابة. [ 4 ] : ​​§9.1Accept-Ranges: bytesConnection: close

معظم حقول الترويسة اختيارية، لكن بعضها إلزامي. عند Content-Lengthغياب الترويسة من استجابة تحتوي على نص، يُعتبر ذلك خطأً في بروتوكول HTTP/1.0، بينما قد لا يُعتبر خطأً في بروتوكول HTTP/1.1 إذا Transfer-Encoding: chunkedكانت الترويسة موجودة. يستخدم ترميز النقل المُجزأ حجمًا للجزء يساوي صفرًا للإشارة إلى نهاية المحتوى. في بعض التطبيقات القديمة لبروتوكول HTTP/1.0، كان يتم حذف الترويسة Content-Lengthعندما يكون طول النص غير معروف في بداية الاستجابة، وبالتالي يستمر نقل البيانات إلى العميل حتى يُغلق الخادم المقبس.

Content-Encoding: gzipيُعلم العميل بأن البيانات مضغوطة وفقًا لخوارزمية gzip .

HTTP / 1.1 200 OK التاريخ : الاثنين، 23 مايو 2005، 22:38:34 بتوقيت غرينتش نوع المحتوى : نص/html؛ ترميز الأحرف: UTF-8 طول المحتوى : 155 تاريخ آخر تعديل : الأربعاء، 8 يناير 2003، 23:11:55 بتوقيت غرينتش الخادم : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" نطاقات القبول : بايت الاتصال : مغلق<html> <head> <title> صفحة مثال < / title > </head> <body> <p> مرحباً بالعالم ، هذه وثيقة HTML بسيطة للغاية . < / p > </body> </html>​​​​​

بروتوكولات مماثلة

بروتوكول غوفر
بروتوكول توصيل المحتوى الذي تم استبداله ببروتوكول HTTP في أوائل التسعينيات.
بروتوكول SPDY
بديل لبروتوكول HTTP تم تطويره في جوجل ، وتم استبداله ببروتوكول HTTP/2 .
بروتوكول جيميني
بروتوكول مستوحى من بروتوكول غوفر يفرض ميزات متعلقة بالخصوصية.

تاريخ

تيم بيرنرز لي

يُنسب الفضل إلى تيم بيرنرز لي وفريقه في سيرن في ابتكار بروتوكول HTTP، إلى جانب لغة HTML والتقنية المرتبطة بها لخادم الويب وواجهة المستخدم الخاصة بالعميل، والتي تُسمى متصفح الويب . صمم بيرنرز لي بروتوكول HTTP للمساعدة في تبني فكرته الأخرى: مشروع "الشبكة العنكبوتية العالمية"، الذي طُرح لأول مرة عام 1989، والمعروف الآن باسم الشبكة العنكبوتية العالمية . بدأ تطوير بروتوكول HTTP عام 1989، ولُخِّص في وثيقة بسيطة تصف سلوك العميل والخادم باستخدام الإصدار الأول من HTTP، والذي سُمي 0.9. [ 42 ] طُوِّر هذا الإصدار لاحقًا، ليصبح في النهاية الإصدار العام 1.0. [ 43 ] بدأ تطوير وثائق طلب التعليقات (RFC) المبكرة لبروتوكول HTTP بعد بضع سنوات في جهد منسق بين فرقة عمل هندسة الإنترنت (IETF) واتحاد شبكة الويب العالمية (W3C)، ثم انتقل العمل لاحقًا إلى فرقة عمل هندسة الإنترنت (IETF).

بدأ تشغيل أول خادم ويب في عام 1990. [ 44 ] [ 45 ] كان البروتوكول المستخدم يعتمد على طريقة واحدة فقط، وهي GET، والتي تطلب صفحة من الخادم. [ 46 ] وكانت الاستجابة من الخادم دائمًا عبارة عن صفحة HTML. [ 42 ]

HTTP/0.9

في عام 1991، كُتبت أول نسخة رسمية موثقة من بروتوكول HTTP كمستند عادي، يقل طوله عن 700 كلمة، وسُميت هذه النسخة HTTP/0.9، والتي كانت تدعم طريقة GET فقط، مما يسمح للعملاء باسترداد مستندات HTML فقط من الخادم، ولكنها لا تدعم أي تنسيقات ملفات أخرى أو تحميل معلومات. [ 42 ]

HTTP/1.0-draft

منذ عام 1992، كُتبت وثيقة جديدة لتحديد تطور البروتوكول الأساسي نحو إصداره الكامل التالي. وقد دعمت هذه الوثيقة كلاً من طريقة الطلب البسيطة للإصدار 0.9 وطلب GET الكامل الذي تضمن إصدار HTTP من جانب العميل. وكانت هذه أولى المسودات غير الرسمية العديدة لبروتوكول HTTP/1.0 التي سبقت العمل النهائي عليه. [ 43 ]

مجموعة عمل بروتوكول HTTP التابعة لاتحاد شبكة الويب العالمية

بعد أن تقرر ضرورة إضافة ميزات جديدة لبروتوكول HTTP وتوثيقها بالكامل كوثائق RFC رسمية، تم تشكيل فريق عمل HTTP (HTTP  WG، بقيادة ديف راجيت ) في أوائل عام 1995 بهدف توحيد البروتوكول وتوسيعه ليشمل عمليات موسعة، ومفاوضات موسعة، ومعلومات وصفية أكثر ثراءً، بالإضافة إلى بروتوكول أمان أصبح أكثر كفاءة من خلال إضافة طرق وحقول رأسية إضافية . [ 47 ] [ 48 ]

خططت مجموعة عمل HTTP لمراجعة ونشر إصدارات جديدة من البروتوكول باسم HTTP/1.0 و HTTP/1.1 خلال عام 1995، ولكن بسبب كثرة المراجعات، استغرق هذا الجدول الزمني أكثر من عام. [ 49 ]

خططت مجموعة عمل HTTP أيضًا لتحديد إصدار مستقبلي بعيد من HTTP يسمى HTTP-NG (الجيل التالي من HTTP) والذي كان من شأنه أن يحل جميع المشاكل المتبقية من الإصدارات السابقة، المتعلقة بالأداء، واستجابات زمن الوصول المنخفض، وما إلى ذلك، ولكن هذا العمل بدأ بعد بضع سنوات فقط ولم يكتمل أبدًا.

HTTP/1.0

في مايو 1996، تم نشر RFC 1945 [ 3 ] كمراجعة نهائية لـ HTTP/1.0 لما تم استخدامه في السنوات الأربع السابقة كمسودة ما قبل المعيار HTTP/1.0 والتي كانت تستخدم بالفعل من قبل العديد من متصفحات الويب وخوادم الويب. 

في أوائل عام 1996، بدأ المطورون في تضمين امتدادات غير رسمية لبروتوكول HTTP/1.0 (مثل اتصالات keep-alive، وما إلى ذلك) في منتجاتهم باستخدام مسودات مواصفات HTTP/1.1 القادمة. [ 20 ]

HTTP/1.1

منذ أوائل عام 1996، بدأت متصفحات الويب الرئيسية ومطورو خوادم الويب بتطبيق الميزات الجديدة المحددة في مسودات مواصفات HTTP/1.1 قبل اعتمادها كمعيار. وكان تبني المستخدمين النهائيين للإصدارات الجديدة من المتصفحات والخوادم سريعًا. في مارس 1996، أفادت إحدى شركات استضافة المواقع الإلكترونية أن أكثر من 40% من المتصفحات المستخدمة على الإنترنت تستخدم رأس HTTP/1.1 الجديد "Host" لتمكين الاستضافة الافتراضية ، وأنه بحلول يونيو 1996، كانت 65% من جميع المتصفحات التي تصل إلى خوادمها متوافقة مع معيار HTTP/1.1 قبل اعتماده كمعيار. [ 50 ]

في يناير 1997، تم إصدار RFC 2068 [ 51 ] رسميًا كمواصفات HTTP/1.1. 

في يونيو 1999، تم إصدار RFC 2616 [ 34 ] ليشمل جميع التحسينات والتحديثات المستندة إلى مواصفات HTTP/1.1 السابقة (القديمة). 

مجموعة عمل W3C HTTP-NG

استكمالاً لخطة عام 1995 التي وضعتها مجموعة عمل HTTP السابقة، شُكّلت في عام 1997 مجموعة عمل HTTP-NG لتطوير بروتوكول HTTP جديد يُسمى HTTP-NG (الجيل الجديد من HTTP). وقُدّمت بعض المقترحات/المسودات للبروتوكول الجديد لاستخدام تعدد إرسال معاملات HTTP ضمن اتصال TCP/IP واحد، ولكن في عام 1999، أوقفت المجموعة نشاطها وأحالت المشكلات التقنية إلى فريق عمل هندسة الإنترنت (IETF). [ 52 ]

أُعيد تشغيل مجموعة عمل بروتوكول الإنترنت التابعة لـ IETF

في عام 2007، أُعيد تفعيل فريق عمل بروتوكول الإنترنت (HTTP WG bis أو HTTPbis) التابع لفرقة عمل هندسة الإنترنت (IETF) بهدف مراجعة وتوضيح مواصفات HTTP/1.1 السابقة، وكتابة وتحسين مواصفات HTTP/2 المستقبلية (المسماة httpbis). [ 53 ] [ 54 ]

SPDY

في عام ٢٠٠٩، أعلنت جوجل عن بروتوكول SPDY ، وهو بروتوكول ثنائي طورته لتسريع حركة البيانات بين المتصفحات والخوادم. في العديد من الاختبارات، كان استخدام SPDY أسرع بالفعل من استخدام HTTP/1.1. تم دمج SPDY في متصفح كروميوم من جوجل ، ثم في متصفحات الويب الرئيسية الأخرى. [ ٥٥ ] استُقيت بعض الأفكار المتعلقة بتعدد إرسال تدفقات HTTP عبر اتصال TCP واحد من مصادر متنوعة، بما في ذلك عمل مجموعة عمل HTTP-NG التابعة لاتحاد شبكة الويب العالمية (W3C).

HTTP/2

في عام ٢٠١٢، أعلنت مجموعة عمل HTTP (HTTPbis) عن الحاجة إلى بروتوكول جديد؛ حيث نظرت في البداية في جوانب من بروتوكول SPDY [ ٥٦ ] [ ٥٧ ] ، ثم قررت في النهاية اشتقاق البروتوكول الجديد من SPDY. [ ٥٨ ] في مايو ٢٠١٥، نُشر بروتوكول HTTP/2 كوثيقة RFC ٧٥٤٠ [ ٥٩ ] . وسرعان ما اعتمدت متصفحات الويب التي كانت تدعم SPDY هذا البروتوكول، بينما اعتمدته خوادم الويب بوتيرة أبطأ. 

تحديثات عام 2014 لبروتوكول HTTP/1.1

في يونيو 2014، أصدرت مجموعة عمل HTTP مواصفات HTTP/1.1 محدثة من ستة أجزاء تلغي RFC 2616 [ 34 ] : 

  • RFC 7230 – " بروتوكول نقل النص التشعبي (HTTP/1.1): بناء الجملة للرسالة والتوجيه، " [ 60 ] قديم. 
  • RFC 7231 – " بروتوكول نقل النص التشعبي (HTTP/1.1): الدلالات والمحتوى، " [ 61 ] قديم. 
  • RFC 7232 – " بروتوكول نقل النص التشعبي (HTTP/1.1): الطلبات المشروطة، " [ 62 ] قديم. 
  • RFC 7233 – " بروتوكول نقل النص التشعبي (HTTP/1.1): طلبات النطاق، " [ 63 ] قديم. 
  • RFC 7234 – " بروتوكول نقل النص التشعبي (HTTP/1.1): التخزين المؤقت، " [ 64 ] قديم. 
  • RFC 7235 – " بروتوكول نقل النص التشعبي (HTTP/1.1): المصادقة، " [ 65 ] قديم. 

إيقاف استخدام HTTP/0.9

في عام 2014، تم إيقاف استخدام بروتوكول HTTP/0.9 للخوادم التي تدعم الإصدار HTTP/1.1 (والإصدارات الأحدث): [ 60 ] : §الملحق أ

بما أن بروتوكول HTTP/0.9 لا يدعم حقول الترويسة في الطلبات، فلا توجد آلية لدعم المضيفات الافتراضية المستندة إلى الاسم (اختيار المورد من خلال فحص حقل ترويسة Host). لذا، ينبغي على أي خادم يُطبّق المضيفات الافتراضية المستندة إلى الاسم تعطيل دعم HTTP/0.9 . معظم الطلبات التي تبدو وكأنها HTTP/0.9 هي في الواقع طلبات HTTP/1.x مُصممة بشكل سيئ نتيجة فشل العميل في ترميز هدف الطلب بشكل صحيح.

منذ عام 2016، بدأ العديد من مديري المنتجات ومطوري وكلاء المستخدم (المتصفحات، وما إلى ذلك) وخوادم الويب في التخطيط لإيقاف دعم بروتوكول HTTP/0.9 تدريجياً، وذلك بشكل رئيسي للأسباب التالية: [ 66 ]

  • الأمر بسيط للغاية لدرجة أنه لم يتم كتابة وثيقة RFC مطلقًا (لا يوجد سوى الوثيقة الأصلية)؛ [ 42 ]
  • لا يحتوي على رؤوس HTTP ويفتقر إلى العديد من الميزات الأخرى المطلوبة في الوقت الحاضر لأسباب أمنية بسيطة؛
  • لم ينتشر على نطاق واسع منذ عام 1999..2000 (بسبب HTTP/1.0 و HTTP/1.1) ويستخدم بشكل شائع فقط بواسطة بعض أجهزة الشبكة القديمة جدًا، مثل أجهزة التوجيه وما إلى ذلك.

حتى عام 2022، لم يتم إيقاف دعم بروتوكول HTTP/0.9 رسميًا وبشكل كامل، ولا يزال موجودًا في العديد من خوادم الويب والمتصفحات (للاستجابات من الخادم فقط)، حتى وإن كان معطلاً في العادة. ومن غير الواضح كم سيستغرق إيقاف دعم HTTP/0.9 نهائيًا.

HTTP/3

في عام 2020، نُشرت المسودات الأولى لبروتوكول HTTP/3، وبدأت متصفحات الويب وخوادم الويب الرئيسية في اعتماده. وفي 6 يونيو 2022، اعتمدت فرقة عمل هندسة الإنترنت (IETF) بروتوكول HTTP/3 كمعيار RFC 9114 [ 67 ] . 

تحديثات وإعادة هيكلة في عام 2022

في يونيو 2022، تم نشر وثائق RFC التي ألغت العديد من الوثائق السابقة وقدمت بعض التغييرات الطفيفة وإعادة هيكلة وصف دلالات HTTP في وثيقة منفصلة.

  • RFC 9110 – " دلالات HTTP، " [ 18 ] معيار الإنترنت 97. 
  • RFC 9111 – " التخزين المؤقت لبروتوكول HTTP، " [ 68 ] معيار الإنترنت 98. 
  • RFC 9112 – " HTTP/1.1, " [ 4 ] معيار الإنترنت 99. 
  • RFC 9113 – " HTTP/2, " [ 6 ] معيار مقترح. 
  • RFC 9114 – " HTTP/3، " [ 67 ] معيار مقترح. (انظر أيضًا القسم أعلاه.) 
  • RFC 9204 – " QPACK: ضغط الحقول لـ HTTP/3، " [ 69 ] معيار مقترح. 
  • RFC 9218 – " مخطط تحديد الأولويات القابل للتوسيع لبروتوكول HTTP، " [ 70 ] معيار مقترح. 

انظر أيضاً

ملحوظات

  1. ↑ من الناحية العملية، تُستخدم هذه التدفقات كوصلات فرعية متعددة لبروتوكول TCP/IP لدمج الطلبات/الاستجابات المتزامنة ، مما يقلل بشكل كبير من عدد اتصالات TCP/IP الحقيقية على جانب الخادم، من 2..8 لكل عميل إلى 1، ويسمح بخدمة عدد أكبر بكثير من العملاء في وقت واحد.
  2. ↑ منذ أواخر عام 1996، بدأ بعض مطوري متصفحات وخوادم HTTP/1.0 الشائعة (وخاصةً أولئك الذين خططوا لدعم HTTP/1.1 أيضًا) في نشر (كإضافة غير رسمية) نوع من آلية إبقاء الاتصال مفتوحًا (باستخدام رؤوس HTTP جديدة) من أجل إبقاء اتصال TCP/IP مفتوحًا لأكثر من زوج طلب/استجابة، وبالتالي تسريع تبادل الطلبات/الاستجابات المتعددة. [ 20 ]

مراجع

  1. 1 2 3 فيلدينغ، روي تي؛ نوتنغهام، مارك؛ ريشكي، جوليان (يونيو 2022). دلالات بروتوكول HTTP (تقرير). فريق عمل هندسة الإنترنت. مؤرشف من الأصل بتاريخ 16 أبريل 2026.
  2. ↑ تي. بيرنرز-لي ؛ آر. فيلدينغ ؛ إل. ماسينتر (يناير 2005). مُعرِّف الموارد الموحد (URI): الصيغة العامة . مجموعة عمل الشبكة. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .المعيار 66 للإنترنت. يلغي المعايير RFC 2732 و 2396 و 1808 . تم تحديثه بواسطة المعايير RFC 6874 و 7320 و 8820 . يُحدّث المعيار RFC 1738 .   
  3. 1 2 3 4 تي بيرنرز-لي ؛ آر. فيلدينغ ؛ إتش. فريستيك (مايو 1996). بروتوكول نقل النص التشعبي - HTTP/1.0 . مجموعة عمل الشبكة. doi : 10.17487/RFC1945 . RFC 1945 .لأغراض إعلامية.
  4. ١ ٢ ٣ ٤ ٥ ٦ ر. فيلدينغ ؛ م. نوتنغهام؛ ج. ريشكي، محررون. (يونيو ٢٠٢٢). HTTP/1.1 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9112 . ISSN 2070-1721 . STD 99. RFC 9112 . معيار الإنترنت 99. عفا عليها الزمن RFC 7230 . 
  5. ↑ "مستندات HTTP الكلاسيكية" . W3.org. 14-05-1998. مؤرشف من الأصل في 11-03-2026 . تم الاطلاع عليه في 01-08-2010 .
  6. 1 2 3 م. طومسون؛ س. بنفيلد، محرران. (يونيو 2022). HTTP/2 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9113 . ISSN 2070-1721 . RFC 9113 . المعيار المقترح. يلغي RFC 8740 و 7540 . 
  7. ↑ "إحصائيات استخدام بروتوكول HTTP/2 للمواقع الإلكترونية" . w3techs.com . تم الاطلاع عليه بتاريخ 21 يناير 2026 .
  8. ↑ "إحصائيات استخدام بروتوكول HTTP/3 للمواقع الإلكترونية، يناير 2026" . w3techs.com . تاريخ الاسترجاع: 21 يناير 2026 .
  9. ↑ "هل يمكنني استخدام... جداول الدعم لـ HTML5 وCSS3 وما إلى ذلك؟" . caniuse.com . تم الاطلاع عليه بتاريخ 2024-01-05 .
  10. ↑ س. فريدل؛ أ. بوبوف؛ أ. لانغلي؛ إ. ستيفان (يوليو 2014). امتداد التفاوض لبروتوكول طبقة التطبيق لأمن طبقة النقل (TLS) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7301 . ISSN 2070-1721 . RFC 7301 . المعيار المقترح. تم تحديثه بواسطة RFC 8447 . 
  11. ↑ "إحصائيات استخدام بروتوكول HTTP/3 للمواقع الإلكترونية" . w3techs.com . تم الاطلاع عليه بتاريخ 18 يناير 2026 .
  12. ↑ "هل يمكنني استخدام... جداول الدعم لـ HTML5 وCSS3 وما إلى ذلك؟" . canIuse.com . تم الاطلاع عليه بتاريخ 2024-01-08 .
  13. ↑ سيمبانو، كاتالين (26 سبتمبر 2019). "Cloudflare وGoogle Chrome وFirefox تضيف دعم HTTP/3" . ZDNet . تم الاطلاع عليه بتاريخ 27 سبتمبر 2019 .
  14. ↑ "بروتوكول HTTP/3: الماضي والحاضر والمستقبل" . مدونة كلاود فلير . 26 سبتمبر 2019. تاريخ الاطلاع: 30 أكتوبر 2019 .
  15. ↑ "يدعم Firefox Nightly بروتوكول HTTP 3 - عام - مجتمع Cloudflare" . 19-11-2019 . تم الاطلاع عليه بتاريخ 23-01-2020 .
  16. ↑ "بروتوكول HTTP/3 سريع" . مقاييس الطلب . تم الاسترجاع في 1 يوليو 2022 .
  17. ↑ "إحصائيات استخدام بروتوكول HTTPS الافتراضي للمواقع الإلكترونية" . w3techs.com . تم الاطلاع عليه بتاريخ 5 يناير 2024 .
  18. ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩ ١٠ ر. فيلدينغ ؛ م. نوتنغهام؛ ج. ريشكي، محررون. (يونيو ٢٠٢٢). دلالات بروتوكول HTTP . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9110 . ISSN 2070-1721 . STD 97. RFC 9110 . المعيار 97 للإنترنت. يلغي المعايير RFC 2818 و 7230 و 7231 و 7232 و 7233 و 7235 و 7538 و 7615 و 7694 . ويُحدّث المعيار RFC 3864 .  
  19. 1 2 "الاتصالات والعملاء والخوادم" . RFC 9110، دلالات HTTP . IETF . القسم 3.3. doi : 10.17487/RFC9110 . RFC 9110 . 
  20. 1 2 ديفيد غورلي؛ برايان توتي؛ مارجوري ساير؛ أنشو أغاروال؛ سايلو ريدي (2002). بروتوكول نقل النص التشعبي (HTTP): الدليل الشامل. (مقتطف من الفصل: "الاتصالات الدائمة") . دار نشر أورايلي ميديا. رقم ISBN 978-1-56592-509-0تم الاطلاع عليه بتاريخ 18-10-2021 .
  21. ↑ لي، وي-بين؛ تشين، هسينغ-باي؛ تشانغ، شون-شيان؛ تشين، تسونغ-هير (25 يناير 2019). "حماية آمنة وفعالة لملفات تعريف الارتباط HTTP مع التحقق الذاتي" . المجلة الدولية لأنظمة الاتصالات . 32 (2) e3857. doi : 10.1002/dac.3857 . S2CID 59524143 . 
  22. ↑ كانافان، جون (2001). أساسيات أمن الشبكات . نوروود، ماساتشوستس: دار أرتيك هاوس. الصفحات 82-83 . ISBN  978-1-58053-176-4.
  23. ↑ زاليفسكي، ميخال. "دليل أمان المتصفح" . تم الاطلاع عليه بتاريخ 30 أبريل 2015 .{{cite web}}: CS1 maint: url-status ( link )
  24. ↑ "Chromium Issue 4527: implement RFC 2817: Upgradeing to TLS Within HTTP/1.1" . تم الاطلاع عليه بتاريخ 30 أبريل 2015 .
  25. ↑ "خطأ موزيلا رقم 276813 - [ طلب ميزة ] دعم RFC 2817 / ترقية TLS لبروتوكول HTTP 1.1" . تم الاطلاع عليه بتاريخ 30 أبريل 2015 .
  26. ↑ HTTP/2 . IETF . يونيو 2022. doi : 10.17487/RFC9113 . RFC 9113 .
  27. ↑ بيون، ر.؛ رويلان، هـ. (مايو 2015). HPACK: ضغط رأس HTTP/2 . IETF . doi : 10.17487/RFC7541 . RFC 7541 .
  28. ↑ "الأساليب: نظرة عامة" . دلالات HTTP . IETF . يونيو 2022. القسم 9.1. doi : 10.17487/RFC9110 . RFC 9110 . 
  29. ↑ "أسماء الحقول" . دلالات HTTP . IETF . يونيو 2022. القسم 5.1. doi : 10.17487/RFC9110 . RFC 9110 . 
  30. ↑ "core - Apache HTTP Server" . Httpd.apache.org. مؤرشف من الأصل بتاريخ 9 مايو 2012. تم الاطلاع عليه بتاريخ 13 مارس 2012 .
  31. ↑ "تحليل الحقول" . بروتوكول نقل النص التشعبي (HTTP/1.1): بناء جملة الرسالة والتوجيه . IETF . يونيو 2014. القسم 3.2.4. doi : 10.17487/RFC7230 . RFC 7230 . 
  32. ↑ "تنسيق الرسالة" . RFC 9112: HTTP/1.1 . IETF . sec. 2.1. doi : 10.17487/RFC9112 . RFC 9112 . 
  33. ↑ "أسبوع أباتشي. HTTP/1.1" . مؤرشف من الأصل بتاريخ 2021-06-02 . تم الاطلاع عليه بتاريخ 2021-05-03 .090502 apacheweek.com
  34. 1 2 3 ر. فيلدينغ ؛ ج. جيتيس؛ ج. موغول؛ هـ. فريستيك ؛ ل. ماسينتر ؛ ب. ليتش؛ ت. بيرنرز-لي (أغسطس 1999). بروتوكول نقل النص التشعبي - HTTP/1.1 . مجموعة عمل الشبكة. doi : 10.17487/RFC2616 . RFC 2616 .مُلغى. أُلغي بموجب RFC 7230 و 7231 و 7232 و 7233 و 7234 و 7235 . يُلغي RFC 2068. تم تحديثه بموجب RFC 2817 و 5785 و 6266 و 6585 .   
  35. ↑ جاكوبس، إيان (2004). "معرّفات الموارد الموحدة، وإمكانية العنونة، واستخدام طلبات HTTP GET وPOST" . نتائج مجموعة الهندسة المعمارية التقنية . اتحاد شبكة الويب العالمية (W3C ). تاريخ الاسترجاع: 26 سبتمبر 2010 .
  36. ↑ "ملاحظة حول الثغرة الأمنية VU#150227: تسمح الإعدادات الافتراضية لخادم وكيل HTTP باتصالات TCP عشوائية" . US-CERT . 17-05-2002 . تم الاطلاع عليه بتاريخ 10-05-2007 .
  37. ↑ ل. دوسولت؛ ج. سنيل (مارس 2010). طريقة PATCH لبروتوكول HTTP . فريق عمل أبحاث الإنترنت . doi : 10.17487/RFC5789 . ISSN 2070-1721 . RFC 5789 . المعيار المقترح.
  38. ↑ ج. ريشكه؛ ج. م. سنيل؛ م. بيشوب (يونيو 2026). طريقة استعلام HTTP . فريق عمل أبحاث الإنترنت . doi : 10.17487/RFC10008 . ISSN 2070-1721 . RFC 10008 . المعيار المقترح.
  39. ↑ إديجر، براد (21-12-2007). ريلز المتقدمة: بناء تطبيقات ويب قوية في وقت قياسي . أورايلي ميديا، ص 188. ISBN  978-0-596-51972-8من الأخطاء الشائعة استخدام طلب GET لتحديث مورد. [...] ظهرت هذه المشكلة للعلن في مجتمع Rails عام 2005، عند إطلاق Google Web Accelerator.
  40. ↑ كانتريل، كريستيان (1 يونيو 2005). "ماذا تعلمنا من مُسرِّع جوجل للويب؟" . مدونات أدوبي . أدوبي. مؤرشف من الأصل في 19 أغسطس 2017. تم الاطلاع عليه في 19 نوفمبر 2018 .
  41. ↑ لوتونين، آري؛ فرانكس، جون (22 فبراير 1996). امتداد استرجاع نطاق البايت لبروتوكول HTTP . IETF. المعرف draft-ietf-http-range-retrieval-00.
  42. 1 2 3 4 تيم بيرنر لي (1991-01-01). "بروتوكول HTTP الأصلي كما تم تعريفه في عام 1991" . www.w3.org . اتحاد شبكة الويب العالمية . تم الاطلاع عليه بتاريخ 24 يوليو 2010 .
  43. 1 2 تيم بيرنر-لي (1992). "بروتوكول HTTP الأساسي كما تم تعريفه في عام 1992" . www.w3.org . اتحاد شبكة الويب العالمية . تم الاطلاع عليه بتاريخ 19-10-2021 .
  44. ↑ "اختراع الويب، تاريخ الويب، من اخترع الويب، تيم بيرنرز لي، روبرت كايليو، سيرن، أول خادم ويب" . LivingInternet . تم الاطلاع عليه بتاريخ 11 أغسطس 2021 .
  45. ↑ بيرنرز-لي، تيم (2 أكتوبر 1990). "daemon.c - خادم قائم على بروتوكول TCP/IP للنصوص التشعبية" . www.w3.org . تاريخ الاسترجاع: 11 أغسطس 2021 .
  46. ↑ بيرنرز-لي، تيم. "بروتوكول نقل النص التشعبي" . اتحاد شبكة الويب العالمية . تم الاطلاع عليه بتاريخ 31 أغسطس 2010 .
  47. ↑ راجيت، ديف. "سيرة ديف راجيت الذاتية" . اتحاد شبكة الويب العالمية . تم الاطلاع عليه بتاريخ 11 يونيو 2010 .
  48. ↑ راجيت، ديف؛ بيرنرز-لي، تيم. "مجموعة عمل بروتوكول نقل النص التشعبي" . اتحاد شبكة الويب العالمية . تم الاسترجاع في 29 سبتمبر 2010 .
  49. ↑ راجيت، ديف. "خطط مجموعة عمل بروتوكول نقل النص التشعبي" . اتحاد شبكة الويب العالمية . تم الاطلاع عليه بتاريخ 29 سبتمبر 2010 .
  50. ↑ "متصفحات متوافقة مع بروتوكول HTTP 1.1" . webcom.com . مؤرشف من الأصل بتاريخ 4 فبراير 1998. تم الاطلاع عليه بتاريخ 29 مايو 2009 .
  51. ↑ ر. فيلدينغ ؛ ج. جيتيس؛ ج. موغول؛ هـ. فريستيك ؛ ت. بيرنرز-لي (يناير 1997). بروتوكول نقل النص التشعبي - HTTP/1.1 . مجموعة عمل الشبكة. doi : 10.17487/RFC2068 . RFC 2068 .قديم. تم إلغاؤه بموجب RFC 2616 . 
  52. ↑ "مجموعة عمل HTTP-NG" . www.w3.org . اتحاد شبكة الويب العالمية. 1997. تم الاطلاع عليه بتاريخ 19-10-2021 .
  53. ↑ مدير الموقع (2007). "مجموعة عمل بروتوكول HTTP" . httpwg.org . IETF . تم الاطلاع عليه بتاريخ 19-10-2021 .
  54. ↑ مسؤول الموقع الإلكتروني (2007). "مجموعة عمل HTTP: ميثاق httpbis" . datatracker.ietf.org . IETF . تم الاطلاع عليه بتاريخ 19-10-2021 .
  55. ↑ "SPDY: بروتوكول تجريبي لشبكة ويب أسرع" . dev.chromium.org . جوجل. 1 نوفمبر 2009. تاريخ الاسترجاع: 19 أكتوبر 2021 .
  56. ↑ "إعادة صياغة بروتوكول HTTP BIS" . IETF؛ مجموعة عمل HTTP. 24-01-2012 . تم الاطلاع عليه بتاريخ 19-10-2021 .
  57. ↑ سكرتير مجموعة هندسة الإنترنت (19 مارس 2012). "إجراء مجموعة العمل: إعادة إحياء: بروتوكول نقل النص التشعبي ثنائي الاتجاه (httpbis)" . فريق عمل هندسة الإنترنت؛ مجموعة عمل بروتوكول نقل النص التشعبي . تم الاطلاع عليه بتاريخ 19 أكتوبر 2021 .
  58. ↑ إيليا غريغوريك؛ سورما (2019-09-03). "شبكات المتصفح عالية الأداء: مقدمة إلى HTTP/2" . developers.google.com . شركة جوجل . تم الاطلاع عليه بتاريخ 2021-10-19 .
  59. ↑ م. بيلشي؛ ر. بيون (مايو 2015). م. طومسون (محرر). بروتوكول نقل النص التشعبي الإصدار 2 (HTTP/2) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7540 . ISSN 2070-1721 . RFC 7540 . المعيار المقترح. تم تحديثه بواسطة RFC 8740 . 
  60. 1 2 ر. فيلدينغ ؛ ج. ريشكي، محرران. (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): بناء الجملة والتوجيه . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7230 . RFC 7230 .مُلغى. أُلغي بموجب RFC 9110 و 9112 . تم تحديثه بموجب RFC 8615. يُلغي RFC 2145 و 2616 . يُحدّث RFC 2817 و 2818 .    
  61. ↑ ر. فيلدينغ ؛ ج. ريشكه، محرران (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): الدلالات والمحتوى . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7231 . RFC 7231 .مُلغى. أُلغي بموجب RFC 9110. يُلغي RFC 2616. يُحدّث RFC 2817 .   
  62. ↑ ر. فيلدينغ ؛ ج. ريشكه، محرران (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): الطلبات المشروطة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7232 . RFC 7232 .مُلغى. تم إلغاؤه بموجب RFC 9110. يُلغي RFC 2616 .  
  63. ↑ ر. فيلدينغ ؛ ي. لافون؛ ج. ريشكه، محرران (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): طلبات النطاق . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7233 . RFC 7233 .مُلغى. تم إلغاؤه بموجب RFC 9110. يُلغي RFC 2616 .  
  64. ↑ ر. فيلدينغ ؛ م. نوتنغهام؛ ج. ريشكه (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): التخزين المؤقت . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7234 . RFC 7234 .مُلغى. تم إلغاؤه بموجب RFC 9111. يُلغي RFC 2616 .  
  65. ↑ ر. فيلدينغ ؛ ج. ريشكه، محرران (يونيو 2014). بروتوكول نقل النص التشعبي (HTTP/1.1): المصادقة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7235 . RFC 7235 .مُلغى. تم إلغاؤه بموجب RFC 9110. يُلغي RFC 2617 و 2616 .  
  66. ↑ مات مينك (30 يونيو 2016). "نية إيقاف دعم HTTP/0.9 وإزالته" . groups.google.com . تم الاطلاع عليه بتاريخ 15 أكتوبر 2021 .
  67. 1 2 م. بيشوب، محرر. (يونيو 2022). HTTP/3 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9114 . ISSN 2070-1721 . RFC 9114 . المعيار المقترح.
  68. ↑ ر. فيلدينغ ؛ م. نوتنغهام؛ ج. ريشكه (يونيو 2022). التخزين المؤقت لبروتوكول HTTP . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9111 . STD 98. RFC 9111 .معيار الإنترنت 98. عفا عليه الزمن RFC 7234 . 
  69. ↑ سي. كراسيك؛ إم. بيشوب (يونيو 2022). أ. فريندل (محرر). QPACK: ضغط الحقول لبروتوكول HTTP/3 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9204 . ISSN 2070-1721 . RFC 9204 . المعيار المقترح.
  70. ↑奥 一穂 (ك. أوكو)؛ ل. باردو (يونيو 2022). مخطط تحديد الأولويات القابل للتوسيع لبروتوكول HTTP . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9218 . ISSN 2070-1721 . RFC 9218 . المعيار المقترح.