ملأ الموقع متصفحك بملفات الارتباط، ثم رفض طلبك لأنك أعدتها إليه

Summary

• يصف RFC 6265 الدورة: يرسل الخادم Set-Cookie، ويعيد المتصفح أزواج الاسم والقيمة المناسبة في Cookie مع الطلبات التالية. ويوصي بأن يقلل الخادم عدد تلك الملفات وحجمها.
• أدخل RFC 6585 في أبريل 2012 الرمز 431 عندما يكبر مجموع الترويسات أو يكبر حقل واحد منها. يمكن إعادة الطلب بعد تقليصه، ولا يجوز تخزين استجابة 431 مؤقتاً.
• ما زال معيارا HTTP/2 وHTTP/3 يسمحان للخادم برفض مجموعة حقول تتجاوز الحجم الذي يقبل معالجته.

عاد الزبون بأمتعة المتجر

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

يرد مسار الذهاب والعودة في RFC 6265 المنشور في أبريل 2011. يرسل الخادم زوج اسم وقيمة عبر Set-Cookie. وفي الطلبات اللاحقة يقرر المتصفح، وفق النطاق والمسار والشروط الأخرى، هل يعيد الزوج داخل Cookie. لا تعود خصائص العمر والنطاق في صورة أزواج من الأسماء والقيم، لكن الاسم والقيمة يعودان. بذلك تتحول استجابة واحدة إلى حمل متكرر على كل طلب يقع ضمن نطاق ذلك الملف.

تكشف أرقام القسم 6.1 من المعيار اختلاف الحسابين. ينبغي للمتصفح العام أن يدعم ما لا يقل عن 4096 بايت للملف الواحد و50 ملفاً للنطاق الواحد. ويطلب النص نفسه من الخوادم تقليل عدد الملفات وحجمها، لأن حقل Cookie يرافق كل طلب تنطبق عليه الشروط. 4096 بايت حد أدنى لقدرة المتصفح على التخزين؛ أما حجم الترويسات الذي تقبله البوابة أو التطبيق فيقرره المستقبل على نحو مستقل. ما يستطيع طرف حفظه قد لا يتسع له مدخل الطرف الآخر.

وضع البروتوكول رقماً على العائق

أضاف RFC 6585 في أبريل 2012 أربعة رموز حالة. الرمز 431، واسمه Request Header Fields Too Large، يصلح عندما يتجاوز مجموع الحقول الحد، وكذلك عندما يكون حقل واحد بالغ الكبر. إذا كان حقل واحد هو السبب، ينبغي أن تسميه الاستجابة. يجوز إرسال الطلب مجدداً بعد تخفيف الترويسات، ويُحظر على الذاكرة المؤقتة حفظ استجابة 431 لتقديمها لطلب آخر.

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

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

الضغط لا يوسع فتحة الاستقبال

بعد عشر سنوات بقي القرار لدى المستقبل. ينص RFC 9113 الصادر عام 2022 على أن خادم HTTP/2 يستطيع الرد بالرمز 431 عندما يكون قالب الحقول أكبر مما يريد معالجته. ويقرر RFC 9114 الأمر نفسه لقسم الترويسات في HTTP/3. يقلل الضغط حجم التمثيل أثناء النقل؛ وما زال المستقبل يواجه الحقول التي عليه قراءتها ويحدد ميزانيتها.

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

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