الخلاصة

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

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

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

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

ما الذي يسمح الحقل بإعادة استخدامه؟

أحدث نص في تاريخ هذا البحث هو draft-ietf-httpbis-no-vary-search-09، وهو Internet-Draft نشط لمجموعة HTTPBIS. مسودة أغسطس 2026 تنتهي في 18 فبراير 2027. يعرض Datatracker تقديمها للنشر وحالة Approved-announcement to be sent::AD Followup، مع Proposed Standard بوصفه وضع RFC المقصود. لقد تقدمت عملية الاعتماد؛ لا يصح تصويرها كفكرة فردية لم تنل أي اعتماد. لكنها لا تُعرض هنا باعتبارها RFC منشورًا بالفعل.

الحقل المقترح قاموس وفق Structured Fields. تسمّي قائمة params المعلمات التي يمكن تجاهل اختلافها. وتحتفظ قائمة except بأهمية المعلمات المذكورة وتتجاهل غيرها. لا يجوز الجمع بين القائمتين. وتحدد القيمة المنطقية key-order ما إذا كان ترتيب أسماء المعلمات مؤثرًا. الصيغة المعروفة غير الصالحة تعود إلى إعداد المقارنة الافتراضي، لا إلى إذن واسع بتجاهل الاستعلام كله.

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

تبقى صلاحية التخزين والعمر والتحقق وشروط التفاوض على المحتوى ذات صلة. No-Vary-Search لا تلغي RFC 9111، ولا تجعل استجابة منتهية صالحة، ولا تستبدل Vary، ولا تساوي بين مستخدمين لمجرد أن بعض معلمات العنوان يمكن إسقاطها من المقارنة. إنها توسع كيفية العثور على مرشح لإعادة الاستخدام، لا صلاحية استعماله في كل سياق.

وتظل المقارنة محصورة في اختلاف الاستعلام مع تطابق المخطط والمضيف والمنفذ والمسار. لا يسمح الحقل بالانتقال بين أصلين أو بين مسارين لمجرد وجود إعلان متشابه. في الوضع الافتراضي تُقارن سلسلة الاستعلام الخام. وفي الوضع غير الافتراضي يطبق النص تحليل application/x-www-form-urlencoded وفق WHATWG، ثم ترشيح أزواج الاسم والقيمة، وترتيبًا مستقرًا بحسب الاسم إن طلب الإعداد ذلك، ثم مقارنة الأزواج المتبقية.

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

التفعيل ليس إعادة كتابة لكل ما حدث قبله

تشرح وثائق Chrome استخدام No-Vary-Search مع التحضير عبر Speculation Rules، بما فيه الجلب المسبق والتصيير المسبق. هذا دليل على سلوك موثق في تلك البيئة، وليس برهانًا على دعم شامل لكل مخزن HTTP.

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

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

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

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

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

الاستجابة المخزنة تحمل سياسة جيلها

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

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

يتناول النص أيضًا الاستجابات ذات Date الأحدث وإعلانات No-Vary-Search غير الفارغة المتعارضة بما يسمح برفض مرشحين ذوي سياسة أقدم. هذا ليس بروتوكول انتقال عالميًا يضمن اختفاء كل كائن قديم لحظة النشر. على اختبار الإصدار أن يشمل الاستجابات التي لا تزال مؤهلة للاستعمال، لا الاستجابات الجديدة وحدها.

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

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

لا يعوّض العميل استجابة غير آمنة

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

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

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

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

المصادر وحدود الدليل

تستند آليات المقارنة والأمان والسياسة المخزنة إلى المسودة والإحالات المعيارية، وتسلسل التفعيل إلى وثائق Chrome. مثال الكتالوج وحدود التسليم واقتراحات الانتقال استنتاجات تحليلية، لا نتائج اختبار منتج أو ادعاءات عن حادثة فعلية. حالة المسودة والدعم قابلة للتغير؛ وتخص القراءة الإصدار التاسع في تاريخ البحث. قراءتا heng.lu توفران إطارًا حوكميًا، ولا تحلان محل المواصفات التقنية.