الخلاصة

  • تسمح RFC 9111 بدمج طلبات لم تجد استجابة مخزنة في طلب واحد مُمرَّر فقط إذا كان يجوز إعادة استخدام الرد للطلبات المعنية.
  • يبقى لكل طلب قيد الانتظار قرار مستقل يتعلق بالهدف والطريقة وحقول Vary والتفويض وضوابط الذاكرة المخبأة.

لنتصور بوابة طرفية في حالة افتراضية بوضوح. يصل طلبا GET لنفس URI في وقت متقارب. الأول مجهول الهوية، والثاني يحمل Authorization وينتظر تمثيلاً خاصاً بالحساب. تختار البوابة الأول قائداً، وترسل طلباً واحداً إلى الخادم الأصلي، ثم توزع 200 OK نفسها على الاثنين. ينخفض الحمل، لكن القرار اللازم للطلب الثاني يختفي داخل التحسين.

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

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

يمثل Vary جزءاً من القرار. تقول RFC 9110 إنه يسمي حقول الطلب التي ربما أثرت في اختيار التمثيل، ويوسع بذلك مفتاح الذاكرة اللازم للمطابقة اللاحقة. وتحدد RFC 9111 كيفية المقارنة، بما فيها التطبيع وحالة غياب الحقول. أما قيمة Vary التي تحتوي * فتفشل دائماً في المطابقة. لا يوحد Vary الطلبات، بل يقدم دليلاً للتمييز بينها.

ويجعل Authorization الحد ملموساً. تمنع RFC 9111 الذاكرة المشتركة من إعادة استخدام استجابة مخزنة لطلب يحوي Authorization في طلبات لاحقة، إلا إذا احتوت الاستجابة توجيه Cache-Control يسمح بذلك والتزمت الذاكرة بمتطلباته. لا يعني هذا أن كل مجموعة مدمجة موثقة الهوية؛ بل يعني أن التوزيع لا يتجاوز ضوابط إعادة الاستخدام المعتادة.

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

يمكن لسجل اعتماد توزيع الاستجابة بعد الدمج أن يحفظ السعة والدليل. هذا تركيب رقابي تحريري، وليس كائناً يعرفه IETF. يربط الطلب المرجعي بكل طلب قيد الانتظار، ويسجل الرد وهوية الكائن المخزن، ويوحد الطريقة والهدف، ويقارن Vary، ويفحص Authorization وCache-Control، ثم يثبت توزيع الرد أو التمرير المنفصل لكل طلب.

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

المصادر