الخلاصة

  • يفرض RFC 9659 على decoder لترميز HTTP zstd دعم Window_Size حتى 8 MB شاملة، ويمنع encoder من إنشاء إطار يحتاج إلى نافذة أكبر.
  • لا يكشف Content-Encoding: zstd قيمة النافذة، ولا يثبت أن intermediary لم يُعد الضغط، أو أن نسخة cache صحيحة، أو أن العملية المستقبلة نجحت.
  • سلسلة الإثبات تربط البايتات الفعلية بإصدار encoder، والتحويلات، ومفتاح cache، والميزانية الفعلية لدى المستقبل، ونتيجة الفك، وقبول التطبيق.

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

يعالج RFC 9659 فجوة محددة في قابلية التشغيل البيني. عند استخدام content coding zstd في HTTP، يجب أن يدعم decoder نافذة حتى 8 MB شاملة، ويجب ألا ينتج encoder إطاراً يحتاج إلى أكثر من 8 MB. يلتزم المنتج والمستقبل بالخط نفسه؛ فلا ينقل المنتج عبئاً غير محدود، ولا يعلن المستقبل دعماً لا يصل إلى الحد المشترك.

النافذة خاصية للبايتات

يعرّف RFC 8878 صيغة Zstandard. تحدد النافذة المسافة القصوى للمراجع إلى محتوى سبق فكّه، ولذلك ترتبط بكمية التاريخ التي قد يحتفظ بها decoder. تسمح الصيغة بقيم من 1 KB إلى نحو 3.75 TB. قد تحسن النافذة الأكبر نسبة الضغط، لكنها ترفع كلفة الذاكرة عند المستقبل.

كان RFC 8878 يوصي بحد 8 MB في سياق HTTP من غير إلزام. كان ممكناً أن يعتبر encoder نافذة أكبر تحسيناً مشروعاً، بينما يرفضها browser أو agent محدود لحماية الذاكرة. يحوّل RFC 9659 التوصية إلى حد قابل للاختبار. يعرض النص القانوني ومصدر XML المتطلبين نفسيهما من دون الاعتماد على تلخيص داخلي.

تسجل صفحة معلومات RFC Editor أن الوثيقة Informational وتحدّث RFC 8878. وتوفر صفحة errata وتاريخ Datatracker مرجعاً لإصدار السياسة: ينبغي أن يعرف المشغل أي نص عام وحالة تصحيح يدّعي تنفيذها.

التفاوض تسمية لا نتيجة

يحدد RFC 9110 معنى content codings. يعلن Accept-Encoding: zstd استعداد المستقبل لقبول الترميز، بينما يصف Content-Encoding: zstd التحويل المطبق على representation المختارة. لا يحمل أي منهما قيمة نافذة Zstandard. ولا يحدد البرنامج الذي أنشأ الإطار، أو ما إذا أعاد وسيط ضغطه، أو الميزانية التي أتاحتها العملية، أو قبول التطبيق للمحتوى.

لهذا لا يساوي عدد استجابات zstd عدد عمليات الفك الناجحة. يستطيع server تسجيل الاختيار قبل إرسال body، ويستطيع edge تسجيل 200 قبل أن يبدأ client الفك. وقد تختبر canary صغيرة مساراً لا يقترب أصلاً من الحد. الاسم يمثل عقداً؛ النتيجة تحتاج قياساً لاحقاً.

يعرض RFC 7694 الفصل نفسه في اتجاه request content. يستطيع server الإعلان عن codings يقبلها، لكن الإعلان لا يثبت صحة body بعينه أو نجاح معالجته. يجب الاحتفاظ بالعرض، والاختيار، والبايتات، والنتيجة كأحداث مختلفة في الاتجاهين.

cache قد يحتفظ بإطار لم تعد السياسة تتذكره

يجعل RFC 9111 cache جزءاً من دلالة التسليم. قد يبقى object مضغوط قديم fresh بعد تعديل encoder. قد تحمل edges أجيالاً مختلفة. قد تصيب عملية purge بعض المفاتيح وتفوت غيرها. وقد يخزّن fallback تحت هوية variant لا تمنع إعادة استخدامه في سياق آخر.

لذلك ليس موضوع التدقيق URL ولا إعداد origin الحالي، بل البايتات المقدمة فعلاً. يجب أن يجمع receipt hash، ومفتاح variant، والجيل، والعمر، وتاريخ invalidation، والتحويلات، وتحليل frame header، وفئة المستقبل. صحة object جديد لا تمحو خطأ object قديم؛ كلاهما حقيقة مستقلة.

يصف سجل IANA لمعاملات HTTP zstd بأنه stream من Zstandard بنافذة لا تزيد على 8 MB. يحمي السجل المعنى العام للرمز، لكنه لا يفتش cache ولا يمنع إعادة ضغط خاطئة. السجل يحدد ما ينبغي أن تعنيه البايتات؛ الالتقاط يثبت ما كانت عليه.

قدرة library ليست ميزانية العملية

قد تدعم library حد 8 MB في اختبارها، ثم تعمل داخل process بحد أدنى بسبب concurrency أو container أو ضغط memory. قد يفشل allocation. وقد ينجح الفك ثم يرفض parser المحتوى. يجب تقييد عبارة «يدعم zstd» بالإصدار، والإعداد، واللحظة، والنتيجة.

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

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

عقد dcz لا يغيّر عقد zstd

يعرّف RFC 9842 Compression Dictionary Transport وترميز dcz. قد يرتبط حد نافذته بحجم dictionary ويصل إلى 128 MB. ذلك سياق وترميز مختلفان، ولا يرفعان سقف zstd العادي في RFC 9659.

يمكن أن تعرض library مشتركة خياراً عاماً باسم window وتخفي الفرق. لذلك يجب أن يتضمن الدليل coding token وهوية dictionary وسياق frame. إعادة استخدام التنفيذ لا تلغي اختلاف العقد العام.

حفظ ما يكفي لإعادة بناء النتيجة

عند المنتج، تُحفظ نسخة encoder وإعداده الفعلي، والترميز، وhash، وframe header. عند كل intermediary، يسجل ما إذا مرر أو فك أو أعاد الضغط أو استبدل. في cache، تحفظ key وgeneration وfreshness وinvalidation. لدى المستقبل، تحفظ version وbudget وwindow وdecode result وerror. وفي التطبيق، يسجل القبول ولا يُستنتج من اكتمال النقل.

يمكن استخدام sampling بدلاً من حفظ كل response، لكنه يجب أن يغطي الحدود: objects كبيرة، أجيال قديمة، edges متعددة، clients محدودة، rollback، fallback، وتغيير مفاتيح. إطار فوق 8 MB، أو اختلاف hash بلا transformation، أو object قديم بعد تعديل cap، أو فجوة بين negotiation وapplication completion كلها إشارات تحقيق.

تقدم Minimum Initial Specification لدى Heng Lu شكلاً مؤسسياً مناسباً: حد عام صغير هو 8 MB ومعنى فشل واضح، وحرية محلية داخله. تمنع Reality Layers الرمز zstd من استعارة سلطة decode success. وتعيد Running-Code Primacy الحكم الأخير إلى الإطار الذي خُدم فعلاً والمستقبل الذي نفذه فعلاً.

يرسم RFC 9659 الخط. حفظ رأس الإطار هو ما يجعل من الممكن إثبات أن البايتات لم تتجاوزه.

المصادر