الخلاصة

  • استجابة 103 معلوماتية، وتسمح للعميل بالتحضير فيما لا يزال الخادم ينشئ الاستجابة النهائية.
  • قد تختلف الحقول المبكرة عن الحقول النهائية، وقد تكون النتيجة نجاحاً أو إعادة توجيه أو خطأ من العميل أو الخادم.
  • يصف رابط preload علاقةً بهدف، ولا يثبت نجاح جلبه أو وجود تفويض لاستخدامه.
  • ينبغي للرصد أن يحفظ سلسلة الاستجابات كاملة ونتائج الطلبات الاستباقية قبل اعتبار Early Hints دليلاً على التوافر.

لنتخيل لوحة تسليم تسجل أول حالة تراها. ترسل الحافة 103 Early Hints مع رابطَي تحميل مسبق، فتتحول اللوحة إلى اللون الأخضر. بعد لحظات ينتهي الطلب نفسه بـ503 Service Unavailable، ويفشل أحد الموردين اللذين جرى طلبهما مبكراً. كانت 103 صحيحة وربما مفيدة، أما استنتاج الجاهزية فلم يكن صحيحاً.

يعرّف RFC 8297 Early Hints لاستغلال الوقت الذي يقضيه الخادم في إعداد الاستجابة النهائية. يستطيع العميل فتح اتصال أو طلب ورقة أنماط يحتمل أن يحتاج إليها. تبدأ الفائدة قبل معرفة النتيجة، وهذا هو سبب وجود الآلية.

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

لا تحل حقول 103 محل حقول الاستجابة النهائية. وخارج تحسين الأداء، لا ينبغي لمعالجتها أن تغير طريقة التعامل مع النتيجة النهائية. التحميل المسبق يهيئ العمل؛ لكنه لا يمنح وصولاً، ولا يختار المحتوى، ولا يحول قراراً معلقاً إلى نجاح.

يوضح RFC 9110 النموذج الأوسع: يمكن أن يقترن طلب واحد بصفر أو أكثر من الاستجابات المؤقتة 1xx، ثم استجابة نهائية واحدة من فئة أخرى. 1xx معلومات عن التقدم، و2xx نجاح، و3xx إعادة توجيه، و4xx حالة خطأ لدى العميل، و5xx إخفاق لدى الخادم. اعتبار 103 نجاحاً يختصر تسلسلاً مرتباً في إشارة مبكرة مضللة.

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

يعرّف RFC 8288 روابط الويب بأنها علاقات ذات أنواع بين مورد سياق وهدف. يمكن لحقل Link بعلاقة preload أن يسمي الهدف ويوجه العميل، لكنه لا يصدق على نجاح DNS أو الاتصال أو TLS أو التفويض أو أهلية التخزين المؤقت أو سلامة الكائن أو اكتمال النقل.

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

للعمل الاستباقي كلفة. قد يستهلك التحميل غير المفيد اتصالاً وعرض نطاق وطاقة ومساحة تخزين مؤقت. يقيد RFC 8297 المعالجة المبكرة لأن تحسين الأداء قد يحدث أثراً أمنياً أو متعلقاً بالخصوصية. المطلوب ليس تعطيل Early Hints، بل جعل نطاقها وكلفتها ونتيجتها قابلة للفحص.

ينبغي لوصل سلسلة HTTP أن يسجل طريقة الطلب وهدفه، والبروتوكول والاتصال وموضع الرصد؛ وكل حالة معلوماتية وحقولها بالترتيب؛ والحالة والحقول النهائية؛ وبصمة التمثيل النهائي عند توافره. ولكل هدف استباقي يسجل نوع العلاقة و103 المحفزة ونمط بيانات الاعتماد ونتيجة الذاكرة المؤقتة والحالة النهائية والسلامة والمدة. ويضيف هوية الوسيط وسياق التفويض والوقت من دون حفظ الأسرار.

عندئذ تفرق اللوحة بين «رُصدت استجابة 103» و«بدأ التحميل المسبق» و«وصلت 200 النهائية» و«تحقق التمثيل» و«اكتملت معاملة التطبيق». يمكن جمعها في شاشة واحدة، لكن الحدث الأول لا يصنع الأربعة الباقية.

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

ضمن حدوده، يقدم Early Hints دليلاً مفيداً: فهو يبين أن سلسلة HTTP المرصودة بلغت مرحلة يمكن فيها إعلان علاقات مؤقتة، وقد يكشف الطلبات الاستباقية المهدرة وتباين الحواف. لكنه لا يستطيع أن يعد باستجابة لم تصل بعد.

المصادر

RFC 8297 — An HTTP Status Code for Indicating Hints; RFC 9110 — HTTP Semantics; RFC 8288 — Web Linking.