الخلاصة

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

لنتصور منصة افتراضية توزع إعداداً خاصاً بكل مستأجر عبر عنوان URI مشترك. يطلب المستأجر «أ» المورد، فيعيد الخادم الأصلي هويته البصرية مع Vary: Accept-Encoding. ترى لوحة الضمان ترويسة صحيحة فتعلن أن العزل سليم. لاحقاً يطلب المستأجر «ب» العنوان نفسه بتفضيل الترميز ذاته، فتسلّمه الحافة بايتات «أ».

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

المعنى الفعلي لـ Vary

تعرّف RFC 9110 ترويسة Vary بأنها حقل استجابة يصف أجزاء الطلب، عدا الطريقة وعنوان URI المستهدف، التي ربما أثرت في اختيار محتوى الاستجابة. وعندما تسرد أسماء حقول فإنها تصبح حقول الاختيار. إنها إذاً إفادة من الخادم الأصلي عن مدخلات محتملة لاختيار استجابة بعينها.

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

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

مفتاح التخزين الفعلي حقيقة منفصلة

تسمي RFC 9111 المعلومات التي تستخدمها ذاكرة التخزين لاختيار استجابة محفوظة «مفتاح التخزين المؤقت». يتكون المفتاح على الأقل من طريقة الطلب وعنوان URI المستهدف، ويمكن إضافة الحقول التي تسميها Vary ومواد أخرى.

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

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

قد يعتمد العزل على أبعاد غير ظاهرة

قد يختار التطبيق التمثيل بحسب حساب موثّق، أو تعيين المستأجر، أو مجموعة ميزة، أو جيل سياسة، أو ولاية قانونية، أو نسخة إعداد الحافة. يظهر بعض ذلك في حقول الطلب، وينشأ بعضه من حالة الخادم. تسمح RFC 9110 بـ Vary: * عندما تؤثر عوامل خارج بنية الرسالة، لكن هذه القيمة تمنع إعادة الاستخدام المعتادة بدلاً من أن تصف قسماً خاصاً قابلاً لإعادة الاستخدام.

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

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

الدليل اللازم لادعاء يمكن الدفاع عنه

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

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

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

المصادر