الخلاصة

  • صدرت RFC 10036 على مسار معايير IETF في أغسطس 2026، وعرّفت حقل HTTP المنطقي Incremental. القيمة ?1 تطلب من الوسيط الداعم أن يمرر محتوى الرسالة كلما وصل؛ ولا تعني أن كل حلقة في المسار قد نفذت الطلب أو أن العميل تلقى تقدماً مفيداً.
  • ينبغي للوسيط الداعم إرسال قسم الترويسات ثم مواصلة إخراج المحتوى من دون انتظار الرسالة كاملة. ويجوز له تجميع الترويسات والمذيّلات وكمية محدودة من المحتوى. أما إذا فهم الحقل ورفض السلوك رفضاً صريحاً، فعليه إرجاع خطأ بدلاً من إخفاء الرفض داخل تخزين كامل وتأخير طويل.

تخيل واجهة إنذار تنتج حدثاً كل ثانية. عند الساعة 10:00:01 كتب الأصل الحدث الأول. مرره الوكيل الأمامي، لكن بوابة الفحص التالية لا تسمح بخروج أي جزء قبل تحليل الجسم كاملاً. وبما أن الاستجابة طويلة العمر، فلن يأتي اكتمال الجسم في الوقت الذي يحتاجه المستخدم. في الساعة 10:05 يبقى كل مكوّن “سليماً” بمقياسه المحلي، وتكون الخدمة قد أخفقت بمقياسها الحقيقي.

الحقل لا يكذب هنا. الخطأ هو افتراض أن التعبير عن النية يساوي السيطرة على التنفيذ.

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

تقدم Server-Sent Events مثالاً مباشراً: تبقى الاستجابة مفتوحة لتسليم أحداث متتابعة؛ وانتظار نهايتها يمنع كل حدث. ويعرض مسودّة Chunked Oblivious HTTP Messages، التي تشير إليها RFC 10036 بوصفها عملاً جارياً، مأزق الاتجاهين: إذا احتاج الخادم إلى بدء الرد قبل أن ينهي العميل الطلب، فقد يوقف التخزين الكامل في أحد الاتجاهين التقدم في كليهما.

لا تلغي RFC 10036 القرار المحلي. إنها تجعل حاجة التطبيق قابلة للقراءة، وتحدد ما يعنيه أن يقول وسيط إنه يفهمها.

قيمة منطقية لا تختصر أربع حالات

الحقل Incremental هو Item وفق Structured Field Values for HTTP، ولا يقبل إلا قيمة منطقية. الصيغة الصحيحة للطلب هي:

Incremental: ?1

وهي تطلب تمرير المحتوى تدريجياً. أما Incremental: ?0 فتبقي الوضع الافتراضي لـ HTTP، حيث يجوز للوسيط انتظار الرسالة كاملة، وقد تمنحه القيمة الصريحة ثقة أكبر لاختيار ذلك. غياب الحقل لا يحمل طلباً بموجب RFC 10036. وإذا كانت القيمة من نوع آخر، يتجاهلها المستلم.

هذه أربع دلالات تشغيلية مختلفة. لا تعد ?1 مفتاح وضعٍ شاملاً من طرف إلى طرف. ولا تأمر ?0 بالتخزين. ولا يعني الغياب رفضاً. كما لا يثبت تجاهل صيغة غير صالحة أن المسار عارض التمرير المتدرج. يجب الاحتفاظ بالقيمة التي وصلت، ونتيجة تحليلها، ومعرفة كل وسيط وسياسة قراره.

يسجل سجل IANA لحقول HTTP الاسم Incremental بصورة دائمة، وبنوع Item المهيكل. يثبت السجل اسماً وقواعد صياغة مشتركة؛ لكنه لا يثبت أن جهازاً بعينه حدّث برمجياته أو أنه أخرج بايتاً في موعده.

الاتجاه خاص بالرسالة لا بالجلسة

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

هذا التفصيل يمنع خطأ شائعاً في الرصد. وصف التبادل كله بعبارة “التدفق مفعّل” يمحو احتمال مرور الاتجاهين عبر محولات وقواعد أمن وحصص سعة مختلفة. وقد تختار إعادة المحاولة حافة أو اتصال أصل آخر. الدليل المفيد يحتفظ بالاتجاه وهوية الرسالة ورقم المحاولة والمسار.

ينبغي للوسيط الداعم الذي يستلم ?1 ألا يجمع الرسالة كاملة. يرسل قسم الترويسات، ثم يمرر بايتات المحتوى باستمرار عند وصولها. مع ذلك، يتعلق الحقل بالمحتوى تحديداً؛ فيجوز جمع قسم الترويسات كاملاً وكذلك قسم المذيّلات كاملاً. “متدرج” لا يعني أن كل بايت يجب أن يتحول فوراً إلى حزمة مستقلة.

تنطبق السلطة المحلية نفسها داخل واجهات البرمجة. قد تعرض مكتبة قارئاً متدفقاً بعدما سلّمها WAF جسماً مجمعاً. وقد يمرر الوكيل الدفعات فوراً فيما يحتفظ إطار التطبيق بها حتى يملأ مخزنه. اسم الواجهة ليس برهاناً على إيقاع البيانات عبر الحدود السابقة أو التالية.

رفض مفهوم يجب أن يظهر كرفض

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

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

يظهر التعارض الدائم عندما تشترط سياسة الأمن رؤية الجسم كاملاً قبل السماح بخروج أي جزء. لا يمكن للبوابة أن تفحص المحتوى كله أولاً وأن تطلق الجزء الأول في الوقت نفسه. توصي RFC 10036 عندئذ بالحالة 501 Not Implemented وخطأ incremental_refused داخل Proxy-Status.

يربط سجل IANA لـ Proxy-Status هذا الخطأ بالحالة 501، ويحدد أن وسيطاً وحده ينشئ تلك الاستجابة. لذلك فهو يحدد فئة قرار في الطريق، لا حكماً من الأصل على العملية التجارية.

أما نقص السعة المؤقت فحالة أخرى. تستهلك التبادلات طويلة العمر اتصالات وفتحات وذاكرة ووقت جدولة. يمكن للوسيط فرض سقف تزامن أقل عليها كي يحمي الطلبات العادية. عند بلوغ السقف توصي RFC 10036 بالحالة 429 Too Many Requests وفق RFC 6585، مع الخطأ connection_limit_reached. تحتاج الأتمتة إلى التفريق بين تعارض أمني دائم وازدحام قد يزول؛ وإلا أعادت المحاولة بالطريقة الخطأ.

التخزين الصغير مباح، لكن الانتظار المفتوح ليس كذلك

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

المهم أن يكون الحد منتهياً. تزيد الدفعات الأكبر الكفاءة، لكنها تزيد زمن الوصول. ويمكن لمسارين يدعيان الدعم أن يقدما تجربتين مختلفتين جذرياً. لهذا يجب التعامل مع حدود التجميع بوصفها قراراً في جودة المنتج، لا إعداداً سرياً داخل وكيل.

ولا يكفي قياس زمن أول بايت. قد يطلق الوسيط بايتاً أولاً بسرعة ثم يصمت. وقد يستلم العميل أجزاء منتظمة لا تكوّن حدثاً قابلاً للاستخدام. وقد تنتهي الرسالة بنجاح بعد أن فاتت كل مواعيد التفاعل.

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

Proxy-Status شاهد محدود لا التقاط كامل للحزم

تتيح RFC 9209 للوسطاء وصف تعاملهم مع الاستجابة بواسطة Proxy-Status. تُرتب العناصر من الوسيط الأقرب إلى الأصل إلى الأقرب لوكيل المستخدم، ويمكن لخطأ أن يشرح استجابة أنشأها وسيط، وقد تضاف معلومات متأخرة في مذيّل في بعض الحالات.

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

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

الحقل لا يقرر أن التطبيق أصبح بروتوكولاً مزدوج الاتجاه

عندما يظهر ?1 في الطلب والرد، يمكن أن يساعد على إنشاء قناة بايتات في الاتجاهين وعلى تمرير رد مبكر قبل اكتمال الطلب. إلا أن RFC 10036 تشير إلى أن Extended CONNECT لـ HTTP/2 وExtended CONNECT لـ HTTP/3 ينسجمان عادة بصورة أفضل مع بنية HTTP للبروتوكولات المزدوجة الحقيقية.

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

يمكن لمعرفة سابقة أو مسبار خاص بالمورد أن يثبت أن مساراً معيناً يعمل الآن. لا ينشئ ذلك قدرة عالمية دائمة. تتغير المسارات وقواعد الفحص والإصدارات والحمل. كما أن بحث أخطاء RFC 10036 لم يعرض نتيجة عند التحقق في 30 أغسطس 2026؛ وهذه ملاحظة مؤرخة عن السجل، لا ضمان للمستقبل.

سلسلة الدليل تبدأ بالنية وتنتهي بالحدث المفيد

يجب أن يحتفظ السجل التشغيلي بالمورد والاتجاه وهوية الطلب والتتبع والمحاولة وإصدار HTTP والاتصالات والمسار؛ والقيمة الدقيقة للحقل عند كل دخول وخروج؛ ونتيجة التحليل؛ وإصدار سياسات الدعم والأمن؛ وقرار قبول السعة؛ وحدود الزمن والبايتات؛ وأوقات الاستلام والإرسال؛ وأطول فجوة؛ وأول حدث مفيد؛ والمذيّلات والإتمام والإلغاء وإعادة الضبط والحالة وProxy-Status.

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

تضع أولوية الشيفرة قيد التشغيل لدى Heng Lu السلطة في التسلسل المنفذ لا في الوثيقة المنشورة. ويوضح مبدأ الحد الأدنى للمواصفة الأولية، والقرار المستقبلي المحلي، والتبني الطوعي لماذا يكفي حقل ضيق للتنسيق، بينما تبقى قرارات الأمن والسعة والبنية عند المشاركين. ويشرح الفرق بين السيطرة التقنية والسيطرة العملية كيف يستطيع المرسل التعبير تقنياً عن رغبة صحيحة من دون أن يمتلك عملياً مخازن المسار.

جعلت RFC 10036 السؤال قابلاً للعبور. أما الإجابة فلا يكتبها إلا تسلسل البايتات الفعلي.