أعلنت Cloudflare إتاحة دعم رأس الاستجابة HTTP Vary ضمن ميزة Cache Rules لجميع خططها، بما في ذلك Free وPro وBusiness وEnterprise. وتمنح الإضافة مسؤولي المواقع تحكماً أكبر في كيفية تعامل الشبكة مع الطلبات التي قد تنتج عنها تمثيلات متعددة للمورد نفسه، مثل اختلاف اللغة أو صيغة الصور أو نوع المحتوى أو أسلوب الضغط.
يحدد الخادم الأصلي عبر Vary رؤوس الطلب التي يمكن أن تؤثر في الاستجابة، لكن الرأس لا يوضح ما إذا كانت كل الاختلافات النصية بين قيم تلك الرؤوس تؤدي فعلاً إلى استجابة مختلفة. لذلك قد يتعامل نظام التخزين المؤقت مع قيم متقاربة باعتبارها نسخاً مستقلة، ما يجزئ المحتوى إلى عدد كبير من العناصر ضعيفة إعادة الاستخدام.
ثلاثة أساليب للتعامل مع الاختلاف
تتيح Cloudflare لكل رأس يذكره المصدر في Vary واحداً من ثلاثة إجراءات:
- normalize: تطبيع القيم قبل اختيار النسخة المخزنة، وهو الخيار الموصى به لرؤوس التفاوض مثل Accept وAccept-Language وAccept-Encoding عندما تتحول قيم كثيرة إلى عدد محدود من الاستجابات.
- passthrough: استخدام القيمة الخام، بما في ذلك حالة الأحرف والمسافات والترتيب والقيم المكررة، عندما يكون الاختلاف الدقيق مؤثراً في الاستجابة.
- bypass: عدم تخزين الاستجابة إذا كان الرأس المذكور في Vary شخصياً أو عالي التعدد، مثل Cookie أو User-Agent.
أما Vary: * فيؤدي دائماً إلى تجاوز التخزين المؤقت، لأن أي جزء من الطلب، بما في ذلك معلومات خارج رسالة HTTP مثل عنوان IP، قد يؤثر في اختيار المصدر للاستجابة.
ما الذي يتغير عملياً؟
عند استخدام التطبيع، يمكن لطلبات مختلفة شكلياً لكنها تفضّل النتيجة نفسها أن تتشارك النسخة المخزنة. وتخفض Cloudflare قيم Accept وAccept-Language وAccept-Encoding إلى صيغة موحدة، فتجعل القيم بحروف صغيرة وترتبها وفق أولوية الجودة، مع ترتيب أبجدي عند التعادل. كما يمكن للمسؤول تحديد أنواع الوسائط أو اللغات المدعومة، مثل text/html وapplication/json أو en وfr وde.
لكن هذا السلوك قد يلغي فروقاً يحتاجها المصدر. وتشير Cloudflare إلى أن قيم q=0 أو بعض استثناءات اللغة قد تضيع أثناء الاختصار، ولذلك ينبغي استخدام passthrough إذا كان المصدر يحتاج إلى رؤية هذه الاستبعادات كما أرسلها العميل. كما أن تمرير القيم الخام قد يعيد مشكلة التجزئة؛ فقيم مثل compact,full وcompact, full قد تنتج مفتاحي تخزين مختلفين حتى لو تعامل المصدر معهما باعتبارهما متكافئتين.
مسؤولية المصدر وحدود التحديث
يجب على المصدر إعادة Vary بصورة متسقة مع كل استجابة قابلة للتخزين يمكن أن تختلف وفق رؤوس الطلب، بما في ذلك الاستجابات الاحتياطية والأخطاء. وإذا أغفلت إحدى الاستجابات الرأس المناسب، فقد تُخزّن Cloudflare تلك الاستجابة دون العزل المطلوب.
لا يؤدي تغيير إعدادات Vary إلى حذف المحتوى الموجود تلقائياً؛ فقد تبقى الإدخالات القديمة حتى انتهاء صلاحيتها أو تنفيذ عملية purge. كما أن إعداد Vary لا يستبدل مفتاح التخزين المخصص في كل الحالات: توصي Cloudflare باستخدام المفتاح المخصص عندما تكون خاصية الطلب جزءاً ثابتاً من هوية المورد، واستخدام Vary عندما يعلن المصدر، استجابةً، الحقول التي تؤثر فعلاً فيها.
لماذا يهم هذا الخبر؟
التحديث يعالج مفاضلة عملية في شبكات CDN: تجاهل Vary قد يرسل صيغة أو لغة خاطئة إلى العميل، بينما التعامل الحرفي مع كل قيمة قد يخفض معدل إصابة الذاكرة ويرفع الطلبات العائدة إلى المصدر. ووفق المادة، أظهر تحليل لأكثر من 120 مليون استجابة من نحو 50 ألف موقع شائع أن قرابة 3 آلاف موقع تستخدم التباين عبر أربعة حقول أو أكثر، وبعضها عبر 10 أو 23 أو 47 حقلاً.
تظل الفائدة مرتبطة بجودة تعريف المصدر للتمثيلات التي يقدمها وباختيار الإجراء المناسب لكل رأس. وتتوفر الإعدادات من لوحة Cloudflare أو Rulesets API أو Terraform، مع ضرورة اختبار القيم المختلفة ومراقبة CF-Cache-Status بعد النشر.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.