الخلاصة

  • تعبّر Incremental: ?1 عن نية المرسل لرسالة HTTP واحدة: أن يبدأ الوسطاء بتمرير المحتوى قبل استلام الرسالة كلها. الطلب والاستجابة رسالتان منفصلتان، لذلك يحتاج كل اتجاه إلى الحقل بنفسه.
  • إذا فهم الوسيط الحقل ورفض نهائياً تمرير الجسم تدريجياً، فعليه إنشاء استجابة خطأ بدلاً من تخزين الرسالة كاملة بصمت. عدم توافق فحص المحتوى يُوصف بـ501 وincremental_refused، وضغط حد التزامن المؤقت بـ429 وconnection_limit_reached.
  • لا ينشئ الحقل ضماناً من طرف إلى طرف. قد يتجاهله وسيط لا يعرفه، وقد يستخدم وسيط داعم مخزناً محدوداً بالوقت أو البايتات. لذلك يجب أن يربط الدليل الاتجاه، وفهم كل وسيط، والسياسة والحدود وسياق الخطأ والزمن المقاس.

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

صدرت RFC 10036، Incremental Forwarding of HTTP Messages، في أغسطس 2026 كمعيار مقترح من IETF، وكتبها Kazuho Oku وTommy Pauly وMartin Thomson. يسرد ملف IETF المحفوظ في 31 أغسطس أربع وثائق RFC لـOku. وتصفه صفحة Fastly بأنه Principal OSS Engineer ومؤلف H2O وquicly وpicoTLS. يثبت ذلك سياقاً مهنياً في برمجيات الإنترنت عالية الأداء، ولا يثبت اختراعاً فردياً أو سيطرة على أي مسار منشور.

النية تخص رسالة واحدة

حقل Incremental هو Item من Structured Fields، ولا تصح فيه إلا قيمة Boolean؛ أما النوع الآخر فيُتجاهل. تطلب ?1 التمرير التدريجي، وتعبّر ?0 عن السلوك المعتاد الذي قد يخزن الرسالة كاملة.

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

ينبغي للوسيط الداعم أن يرسل قسم الرؤوس ثم يمرر بايتات المحتوى باستمرار عند وصولها. ويمكنه تخزين الرؤوس والـtrailers كاملة. كما تشير الوثيقة إلى أن Extended CONNECT يكون عادةً أكثر اتساقاً مع بنية HTTP عند تصميم بروتوكول ثنائي الاتجاه فعلي؛ فالحقل لا يحل محل اختيار البنية.

لا يجوز إخفاء الرفض داخل نجاح متأخر

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

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

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

قيد أمني دائم أم ازدحام مؤقت

تحتاج بعض وظائف الفحص إلى رؤية الجسم كاملاً قبل السماح بتمريره. وهذا يتعارض مع التسليم التدريجي. توصي RFC 10036 عندئذٍ بـ501 Not Implemented مع incremental_refused في Proxy-Status. لا يُرجح أن تنجح إعادة المحاولة ما لم يتغير الفحص أو المسار أو المورد أو البروتوكول.

السبب الثاني هو السعة. قد تشغل الطلبات التدريجية الموارد زمناً أطول، فيخصص الوسيط لها حداً أقل للتزامن كي يحمي بقية الحركة. وعند امتلاء الحد، توصي الوثيقة بـ429 Too Many Requests مع connection_limit_reached.

هنا قد يكون المورد متوافقاً ولكن لا توجد سعة لحظية. التراجع الزمني، وسياسة القبول، والأولوية والتوسعة هي الاستجابات المناسبة. جمع السببين في عبارة «فشل البث» يزيل الفرق الذي يحدد العلاج.

رمز الحالة وحده لا يكفي؛ لـ501 و429 استخدامات أخرى. يجب ربطه بـProxy-Status والوسيط المسؤول والمورد وإصدار السياسة والوقت. وغياب وسيط غير مشارك يبقى فجوة في الدليل.

الوسيط غير المدرك يستطيع البقاء صامتاً

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

المفارقة أن الوسيط الداعم الذي يرفض أكثر شفافية من وسيط غير مدرك يؤخر البيانات ثم يمررها. يمكن لمعلومة سابقة مختبرة أن تقلل الغموض في مسار مضبوط؛ وإلا فتوصي الوثيقة بفحص الموارد منفردة.

قد تختلف سياسة الاسم نفسه حسب المنطقة والمسار ونوع الجسم وفئة العميل والحمل. نتيجة ناجحة تثبت ظروفها المؤرخة، ولا تمنح مؤسسة أو نطاقاً شهادة دائمة.

حد السلطة واضح: يعبّر المرسل عن نية؛ يقرر كل وسيط أمنه وسعته وتمريره؛ ويفسر الطرف النتيجة. لا يستطيع طرف أن يَعِد نيابةً عن برمجيات لا يسيطر عليها.

حتى المخزن المحدود يغير النتيجة

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

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

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

وصل المسار بالنتيجة في سجل واحد

يسجل الإثبات العميل والخادم والمورد والإصدار ومعرّف الرسالة والاتجاه. ويحفظ قيمة الحقل وصحة Boolean والمكوّن الذي وضعها. ولكل وسيط مضبوط أو مشارك، يحتفظ بمقطع البروتوكول وحالة الفهم والدعم وقاعدة الفحص وسياسة الجسم والرؤوس والـtrailers وحدود الزمن والبايتات ومجموعة التزامن وإشغالها.

ثم يربط حالة HTTP وعضو Proxy-Status ونوع الخطأ والوسيط المسؤول وأوقات أول وآخر بايت عند الاستلام والتمرير. ويفصل بين تسليم تدريجي مقبول، وتدهور بسبب مخزن محدود، ورفض بنيوي، ورفض مؤقت، وتخزين صامت محتمل، ودليل غير حاسم.

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

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

المصادر