تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دعم رؤوس استجابة HTTP

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

يصف هذا الموضوع كيفية معالجة Edge لرؤوس التخزين المؤقت لبروتوكول HTTP/1.1 عند استخدام سياسة ResponseCache. تتيح Apigee Edge حاليًا مجموعة فرعية من رؤوس ذاكرة التخزين المؤقت وتوجيهات HTTP/1.1 (يتم إدراج الميزات غير المتوافقة في هذا الموضوع) التي يتم تلقّيها من خوادم الوجهة (المصدر) في الخلفية.

بالإضافة إلى ذلك، يتّخذ Edge إجراءً استنادًا إلى توجيهات رؤوس معيّنة. في بعض الحالات، تلغي عناوين ذاكرة التخزين المؤقت هذه في HTTP/1.1 أي سلوك محدّد في سياسة ResponseCache. على سبيل المثال، إذا تم عرض الرأس Cache-Control من خادم خلفية، يمكنك أن تجعل توجيه s-maxage للرأس يتجاوز إعدادات انتهاء الصلاحية الأخرى في السياسة.

ملاحظة: توضّح مواصفة HTTP/1.1 عناوين التخزين المؤقت العادية وآليات التحكّم التي تتيح التخزين المؤقت على مستوى سلسلتَي طلب/استجابة HTTP. تقدّم هذه الرؤوس والآليات معلومات عن الموارد المخزّنة مؤقتًا. وتساعد هذه البيانات أيضًا الخوادم في تحديد كيفية إدارة البيانات المخزّنة مؤقتًا. تحتوي المواصفة نفسها على معلومات detailed حول التخزين المؤقت في HTTP. تتوفّر أيضًا العديد من المدونات والمقالات وغيرها من المراجع على الإنترنت التي توضّح ميزة التخزين المؤقت لبروتوكول HTTP.

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

‫<UseResponseCacheHeaders> - عند ضبط هذا الخيار على true، سيأخذ Edge في الاعتبار رؤوس استجابة HTTP المستخدَمة عند ضبط "مدة البقاء" (TTL) للاستجابة في ذاكرة التخزين المؤقت. لمعرفة التفاصيل، يُرجى الاطّلاع على "ضبط انتهاء صلاحية إدخال ذاكرة التخزين المؤقت" و <UseResponseCacheHeaders> في سياسة ذاكرة التخزين المؤقت للاستجابة.
<UseAcceptHeader> - عند ضبط هذا الخيار على true، سيستخدم Edge رؤوس الاستجابة Accept لإضافة مفتاح ذاكرة التخزين المؤقت. لمزيد من المعلومات، يُرجى الاطّلاع على <UseAcceptHeader> في سياسة ذاكرة التخزين المؤقت للإجابات.

العنوان	الدعم
Cache-Control	تتوفّر هذه الميزة للاستجابات التي يتم عرضها من خوادم المصدر في الخلفية، ولكن ليس لطلبات العميل. يتوافق Edge مع مجموعة فرعية من الإرشادات.
تاريخ انتهاء الصلاحية	متاح يمكن إلغاء هذا الخيار.
علامات الكيانات (ETags)	سلوك محدّد لـ If-Match و If-None-Match
If-Modified-Since	في طلبات GET، يتم تمرير الرأس إلى خادم المصدر حتى إذا كان هناك إدخال صالح في ذاكرة التخزين المؤقت.
Accept-Encoding	يُرسِل Edge ردودًا مضغوطة أو غير مضغوطة استنادًا إلى عناوين العميل القادمة.

Cache-Control

لا تتيح Apigee Edge استخدام الرأس Cache-Control إلا في الردود التي يتم عرضها من خوادم المصدر في الخلفية (تسمح مواصفات HTTP/1.1 باستخدام رؤوس Cache-Control في كل من طلبات العميل وردود خادم المصدر). يمكن أن تتضمّن خوادم المصدر كلّ من نقاط النهاية المستهدفة المحدّدة في وكيل واجهة برمجة التطبيقات Apigee Edge API وتلك التي تم إنشاؤها باستخدام طلبات البيانات من واجهة برمجة التطبيقات TargetServer API.

القيود المفروضة على إتاحة عناصر التحكّم في ذاكرة التخزين المؤقت

تتوافق Apigee Edge مع مجموعة فرعية من إمكانات عناوين استجابة Cache-Control المحدّدة في مواصفات HTTP/1.1. ملاحظات:

لا تتوافق Apigee Edge مع عناوين Cache-Control التي تصل مع طلبات العميل القادمة.
لا يتيح Apigee Edge سوى ميزة ذاكرة التخزين المؤقت العلنية. (وفقًا لمواصفات HTTP ، يمكن أن يكون Cache-Control متاحًا للجميع (مشترَكًا) أو خاصًا (مستخدم واحد ).)
لا تتوافق Apigee Edge إلا مع مجموعة فرعية من توجيهات الاستجابة Cache-Control في مواصفة HTTP/1.1. اطّلِع على إتاحة توجيهات عنوان الاستجابة Cache-Control للاطّلاع على التفاصيل.

إتاحة توجيهات عنوان الاستجابة Cache-Control

تتوافق Apigee مع مجموعة فرعية من تعليمات مواصفات HTTP/1.1 بشأن الردود الواردة من خوادم المصدر. يوضِّح الجدول التالي مدى توافق Apigee Edge مع توجيهات عنوان استجابة HTTP Cache-Control.

للحصول على معلومات أكثر تفصيلاً عن التعليمات المدرَجة هنا، اطّلِع على Cache-Control في مواصفات HTTP/1.1.

توجيه Cache-Control	كيفية معالجة Apigee Edge للتوجيه
`cache-extension`	غير مدعوم.
`max-age`	إذا كانت سياسة ResponseCache تضبط العنصر `<UseResponseCacheHeaders>` على `true`، يمكن تخزين الاستجابة مؤقتًا لعدد الثواني الذي تحدّده هذه التعليمات. يتم إلغاء هذا التوجيه من خلال توجيه `s-maxage`، كما يلغى بدوره عنوان `Expires`. ويمكن أيضًا إلغاء هذا الإعداد من خلال عنصر `<ExpirySettings>` في السياسة. لمزيد من المعلومات، اطّلِع على "ضبط انتهاء صلاحية إدخال ملف التخزين المؤقت" و`<UseResponseCacheHeaders>` في سياسة ذاكرة التخزين المؤقت للردّ. ملاحظة: سيحتفظ المحتوى المخزّن مؤقتًا باستخدام سياسة ResponseCache بقيمة max-age التي ضبطها مصدره. وهذا يعني أنّه عند استرجاع المحتوى من ذاكرة التخزين المؤقت، قد يكون أقدم من القيمة التي تشير إليها max-age (أقدم من القيمة التي يعرفها العميل ).
`must-revalidate`	غير مدعوم. تحذف Apigee Edge جميع إدخالات ذاكرة التخزين المؤقت فور انتهاء صلاحيتها.
`no-cache`	تخزِّن Edge استجابة المصدر، ولكن يجب إعادة التحقّق منها مع خادم المصدر قبل استخدامها لتلبية أي طلبات لاحقة من العميل. تسمح هذه القاعدة لمصدر المحتوى بإرسال استجابة 304 "لم يتم التعديل" للإشارة إلى أنّه يجب عرض الاستجابة من ذاكرة التخزين المؤقت، وبالتالي توفير المعالجة المطلوبة لعرض الاستجابة بأكملها. إذا أرجع خادم المصدر استجابة كاملة، يتم استبدال إدخال ذاكرة التخزين المؤقت الحالي. ويتم تجاهل أي أسماء حقول تم تحديدها باستخدام هذا التوجيه. ملاحظة: يتم التعامل مع عنوان HTTP/1.0‏، `Pragma: no-cache` على أنّه مكافئ لعنوان `Cache-Control: no-cache`.
`no-store`	غير مدعوم.
`no-transform`	غير مدعوم.
`private`	غير مدعوم. في حال تلقّي هذا التوجيه، لا يتم تخزين ردّ المصدر مؤقتًا. ويتم تجاهل أي أسماء حقول.
`proxy-revalidate`	غير مدعوم. تحذف Apigee Edge جميع إدخالات ذاكرة التخزين المؤقت فور انتهاء صلاحيتها.
`public`	تُخزِّن Edge استجابة المصدر في ذاكرة التخزين المؤقت، حتى إذا كانت توجيهات أخرى تشير إلى خلاف ذلك. وفقًا لمواصفات HTTP/1.1، فإنّ الاستثناء الوحيد لهذه القاعدة هو إذا كانت الاستجابة تتضمّن عنوان Authorization.
`s-maxage`	إذا كانت سياسة ResponseCache تضبط العنصر `<UseResponseCacheHeaders>` على `true`، يمكن تخزين الاستجابة مؤقتًا لعدد الثواني الذي تحدّده هذه التعليمات. تلغي هذه التعليمات توجيه `max-age` وعنوان `Expires`. ويمكن إلغاء هذا الإعداد باستخدام عنصر `<ExpirySettings>` في السياسة. لمزيد من المعلومات، اطّلِع على "ضبط انتهاء صلاحية إدخال ملف التخزين المؤقت" و`<UseResponseCacheHeaders>` في سياسة ذاكرة التخزين المؤقت للردّ. ملاحظة: سيحتفظ المحتوى المخزّن مؤقتًا باستخدام سياسة ResponseCache بقيمة s-maxage التي ضبطها مصدره. وهذا يعني أنّه عند استرجاع المحتوى من ذاكرة التخزين المؤقت، قد يكون أقدم من القيمة التي تشير إليها s-maxage (أقدم من القيمة التي يعرفها العميل ).

تاريخ انتهاء الصلاحية

عند ضبط العلامة UseResponseCacheHeaders في سياسة ResponseCache على true، يمكن أن يستخدم Edge العنوان Expires لتحديد مدة البقاء (TTL) لإدخال محفوظ في ذاكرة التخزين المؤقت. يحدِّد هذا العنوان تاريخًا أو وقتًا بعدهما يتم اعتبار إدخال ذاكرة التخزين المؤقت للاستجابة قديمًا. يسمح هذا العنوان للخوادم بإرسال إشارة عندما يكون من المقبول عرض قيمة محفوظة مؤقتًا استنادًا إلى الطابع الزمني.

ملاحظة: تُمنَح توجيهات عنوان Cache-Control max-age وs-maxage الأولوية على عنوان Expires وتلغيه. لمزيد من المعلومات، اطّلِع على "ضبط انتهاء صلاحية إدخال ذاكرة التخزين المؤقت" و <UseResponseCacheHeaders> في سياسة ذاكرة التخزين المؤقت للاستجابة.

يتم وصف تنسيقات التاريخ المقبولة لعنوان Expires في مواصفات HTTP/1.1. على سبيل المثال:

تاريخ انتهاء الصلاحية: الخميس 1 كانون الأول (ديسمبر) 1994، الساعة 4:00:00 مساءً بتوقيت غرينيتش

للحصول على معلومات تفصيلية حول تنسيقات التاريخ/الوقت في HTTP، يُرجى الاطّلاع على تنسيقات التاريخ/الوقت في مواصفات HTTP/1.1.

ملاحظة: على الرغم من أنّ القسم 14.21 من المواصفة يشير إلى أنّ قيمة Expires التي تزيد عن عام واحد في المستقبل تعني أنّ إدخال ذاكرة التخزين المؤقت لن يتم نتهاؤه أبدًا، تفسّر Apigee هذه القيمة على أنّه يجب تخزين الإدخال في ذاكرة التخزين المؤقت إلى الموعد والوقت المحدّدَين.

لمزيد من المعلومات عن رأس Expires، راجِع تعريفات حقول الرأس في مواصفات HTTP/1.1.

علامة ETag

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

عندما تُرسِل نقطة نهاية مستهدَفة استجابةً إلى Edge تتضمّن علامة ETag، يخزِّن Edge علامة ETag مع الاستجابة.

يمكنك الاطّلاع على مزيد من المعلومات حول علامات الكيانات في مَعلمات البروتوكول ضمن مواصفات HTTP/1.1.

If-Match

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

يمكنك الاطّلاع على مزيد من المعلومات حول If-Match في تعريفات حقول الرأس في مواصفات HTTP/1.1.

إذا تلقّى Edge طلب GET واردًا من عميل يتضمّن رأس If-Match:

إذا	بعد ذلك
يحدّد العنوان `If-Match` علامة ETag واحدة أو أكثر.	يسترجع Apigee Edge أي إدخالات ذاكرة تخزين مؤقت لم تنته صلاحيتها للمورد المحدّد ويقارن أي علامات ETag قوية في هذه الإدخالات المخزّنة مؤقتًا بتلك المحدّدة في عنوان `If-Match`. في حال العثور على مطابقة، يتم عرض إدخال ذاكرة التخزين المؤقت. وإذا لم يكن الأمر كذلك، يتم تمرير الطلب إلى الخادم المصدر.
يحدِّد العنوان `If-Match` القيمة "*".	يتم تمرير الطلب إلى خادم المصدر لضمان توفُّر فرصة لمعالجة الطلب في أي مرافق ذاكرة التخزين المؤقت للمصدر .
تم العثور على إدخال في ذاكرة التخزين المؤقت يحتوي على معرّف الموارد المنتظم للطلب نفسه، ولكنه لا يحتوي إلا على علامات ETag ضعيفة.	يجب أن يعيد خادم المصدر التحقّق من صحة الإدخال قبل إرجاعه إلى العميل.
تأتي علامات ETag من خادم المصدر.	يتم عرض علامة ETag بدون تغيير للعميل.

If-None-Match

باستخدام عنوان If-None-Match، يكون العنصر المخزّن مؤقتًا حاليًا إذا كان علامة الهامش في عنوان لا تتطابق مع علامة الهامش المخزّنة مؤقتًا. يتمّ توجيه الطلبات غير طلبات GET التي تحتوي على عنوان هذا إلى خادم المصدر.

إذا تلقّى Edge طلب GET واردًا يتضمّن هذا العنوان:

إذا	بعد ذلك
يحدّد العنوان `If-None-Match` علامة ETag واحدة أو أكثر.	يسترجع Apigee Edge أي إدخالات ذاكرة تخزين مؤقت لم تنته صلاحيتها لمعرّف الموارد المنتظم المحدّد ويقارن أيّ علامات ETag قوية في هذه الإدخالات المخزّنة مؤقتًا بتلك المحدّدة في عنوان `If-None-Match`. في حال العثور على مطابقة، يعرض Edge الحالة 304 "لم يتم التعديل". في حال عدم العثور على أي تطابق، يُرسِل Edge الطلب إلى الخادم المصدر.
يحدّد عنوان `If-None-Match` القيمة "*"، ويشير إلى توفّر إدخال في ذاكرة التخزين المؤقت لمعرّف الموارد المنتظم (URI) الذي تمّ طلبه ولم تنتهي صلاحيته.	يعرض Edge حالة 304 "لم يتم التعديل".
تم العثور على إدخال في ذاكرة التخزين المؤقت يحتوي على معرّف الموارد المنتظم للطلب نفسه، ولكنه يحتوي على علامات ETag ضعيفة فقط.	يجب أن يعيد خادم المصدر التحقّق من صحة الإدخال قبل أن يعرضه Edge على العميل.
يتلقّى Edge علامة ETag من خادم مصدر	يتم عرض علامة ETag بدون تغيير للعميل.

If-Modified-Since

إذا تلقّى Apigee Edge عنوان If-Modified-Since في طلب GET، تتم его تمريره إلى خادم المصدر حتى في حال توفّر إدخال صالح في ذاكرة التخزين المؤقت.

يضمن ذلك مراعاة أي تعديلات على مورد لم يجتَز Apigee Edge. إذا عرض خادم المصدر عنصرًا جديدًا، يستبدل Edge إدخال ذاكرة التخزين المؤقت الحالي بالقيمة الجديدة. إذا عرض الخادم الحالة 304 "لم يتم التعديل"، يعرض Edge قيمة الردّ إذا كان عنوان Last-Modified للردّ المخزّن مؤشرًا على أنّه لم يتغيّر.

Accept-Encoding

عندما يتضمّن الطلب الوافد العنوان Accept-Encoding بالقيم gzip أو deflate أو compress، يستجيب خادم المصدر بتقديم بيانات مضغوطة. عندما تأتي الطلبات اللاحقة بدون رؤوس Accept-Encoding، يتوقّع الخادم استجابة غير مضغوطة. يمكن لآلية التخزين المؤقت للاستجابات في Apigee إرسال كلّ من الاستجابات المضغوطة وغير المضغوطة استنادًا إلى العناوين الواردة بدون الرجوع مجددًا إلى خادم المصدر.

يمكنك إلحاق قيم رأس Accept بمفاتيح ذاكرة التخزين المؤقت لجعل المفاتيح أكثر ملاءمةً لكل عنصر محفوظ في ذاكرة التخزين المؤقت. لمزيد من التفاصيل، يُرجى الاطّلاع على "ضبط مفتاح ذاكرة التخزين المؤقت" في سياسة ذاكرة التخزين المؤقت للاستجابة.