الخلاصة

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

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

RFC 9651 يعالج مشكلة مختلفة ومحددة. فهو يقدم نماذج بيانات مشتركة وسلوكاً صارماً لتسلسل حقول HTTP وتحليلها. يستطيع مؤلف الحقل الجديد أن يختار Item أو List أو Dictionary بدلاً من اختراع قواعد متشابهة للمفاتيح والقيم والمعلمات في كل مرة. والنتيجة أن تطبيقين حذرين يستطيعان تحويل القيمة نفسها إلى الشكل المجرد نفسه. تلك فائدة للتشغيل البيني، وليست تفويضاً لاتخاذ قرار.

النص يصر على هذا الفصل. فعند تعريف Structured Field لا يكفي ذكر نوعه ومكانه في header أو trailer. يجب أن يعرّف المؤلف دلالة القيمة، والقيود الإضافية، وما الذي يحدث عند خرقها. لا يستطيع محلل عام أن يعرف إن كانت كلمة ما تمثل تفضيلاً أو تشخيصاً أو إشارة قدرة أو امتداداً ينبغي تجاهله. القواعد النحوية مشتركة؛ أما الأثر فمسؤولية تعريف الحقل المعين.

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

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

ثم تأتي دلالة الحقل الخاصة. عمود Structured Type في سجل أسماء حقول HTTP لدى IANA يصف الشكل: Dictionary أو List أو Item. لا يسجل معنى موحداً، ولا يمنح سلطة موحدة. على المستهلك الرجوع إلى مواصفة اسم الحقل: الأعضاء المسموحون، المجال، القيود، والنتيجة المطلوبة عند المخالفة. قد تكون القيمة Dictionary صحيحة تماماً ولا يكون لها أي أثر في هذا endpoint.

ويجب أيضاً حماية السياق. يحذر RFC 9651 من أن من يستطيع حقن حقول HTTP جديدة قد يغير معنى Structured Field، وليس من الممكن الاعتماد دائماً على فشل التحليل لاكتشاف ذلك. إذا كانت مقاومة العبث مهمة، فالحماية اختيار صريح. تحمي TLS علاقة نقل، ويمكن للتوقيع أن يغطي مكونات مختارة. في RFC 9421 يجب تحديد ما الذي غُطي وكيف جرى التحقق منه. الكائن الذي أعاده المحلل لا يحمل تلقائياً برهان توقيع أو برهان تغطية.

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

الانتقال من RFC 8941 إلى RFC 9651 يوضح ذلك أيضاً. قد يقبل محلل أحدث قيمة كان محلل أقدم يرفضها. لا يوسّع ذلك تلقائياً عقد الحقول التي عُرّفت في السابق؛ فالتطبيق الخاص بالحقل ما زال يقرر قبول Date أو معلمة أو امتداد جديد. اتساع ما يمكن قراءته لا يعني اتساع ما يستطيع المرسل فرضه.

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

المصادر