תמיכה בכותרות של תגובת HTTP

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

במאמר הזה מוסבר איך Apigee מטפל בכותרות של HTTP/1.1 caching כשמשתמשים במדיניות ResponseCache. בשלב הזה, Apigee תומך בחלק מהכותרות וההוראות של HTTP/1.1 בנושא שמירת נתונים במטמון (תכונות שלא נתמכות מפורטות בנושא הזה) שמתקבלות משרתי יעד (מקור) של קצה עורפי.

בנוסף, עם כותרות מסוימות, Apigee מבצע פעולה על סמך ההנחיות שלהן. במקרים מסוימים, כותרות המטמון האלה של HTTP/1.1 מבטלות את כל ההתנהגויות שמוגדרות במדיניות ResponseCache. לדוגמה, אם הכותרת Cache-Control מוחזרת משרת קצה עורפי, יכול להיות שההנחיה s-maxage בכותרת תבטל הגדרות אחרות של תפוגה במדיניות.

הערה: במפרט HTTP/1.1 מתוארות כותרות סטנדרטיות של מטמון ומנגנוני בקרה שתומכים במטמון לאורך שרשרת הבקשות והתגובות של HTTP. הכותרות והמנגנונים האלה מספקים מידע על משאבים שנשמרו במטמון. הן גם עוזרות לשרתים לקבוע איך לנהל נתונים במטמון. המפרט עצמו מכיל מידע מפורט על שמירה במטמון ב-HTTP. יש גם הרבה בלוגים, מאמרים ומשאבים אחרים באינטרנט שמסבירים על שמירת נתונים במטמון של HTTP.

הערה: שימוש בכותרות כדי להשפיע על מפתחות מטמון ועל TTL של רשומות במטמון אפשר להגדיר ש-Apigee ישתמש בכותרות של תגובות כשיוצרים מפתחות של מטמון תגובות ומגדירים TTL של רשומות במטמון. כדי לעשות את זה, משתמשים ברכיבי הדגל האלה של מדיניות ResponseCache:

• ‫<UseResponseCacheHeaders> -- כשהערך הזה מוגדר ל-true, מערכת Apigee תתייחס לכותרות של תגובות HTTP שמשמשות להגדרת ה-TTL של התגובה במטמון. פרטים נוספים זמינים במאמר בנושא הגדרת תפוגה של רשומת מטמון ובמאמר בנושא מדיניות מטמון התגובות.<UseResponseCacheHeaders>
• ‫<UseAcceptHeader> -- אם הערך מוגדר כ-true, מערכת Apigee תשתמש בכותרות של תגובות Accept כדי להוסיף למפתח המטמון. מידע נוסף זמין במאמר בנושא מדיניות שמירת תשובות במטמון בקטע <UseAcceptHeader>.

כותרת	תמיכה
סמל המטמון	התמיכה קיימת בתגובות שמוחזרות משרתי מקור של קצה עורפי, אבל לא בבקשות של לקוחות. ‫Apigee תומך בקבוצת משנה של הנחיות.
תאריך התפוגה	יש תמיכה. אפשר לשנות את ההגדרה הזו.
תגי ישות (ETags)	התנהגות ספציפית של If-Match ושל If-None-Match.
If-Modified-Since	בבקשות GET, הכותרת מועברת לשרת המקור גם אם קיים רשומה תקפה במטמון.
Accept-Encoding	‫Apigee שולח תגובות דחוסות או לא דחוסות, בהתאם לכותרות הנכנסות.

סמל המטמון

‫Apigee תומך בכותרת Cache-Control רק בתגובות שמוחזרות משרתי מקור של קצה עורפי (במפרט HTTP/1.1 מותרות כותרות Cache-Control גם בבקשות של לקוחות וגם בתגובות של שרתי מקור). שרתי מקור יכולים לכלול גם נקודות קצה של יעד שהוגדרו ב-proxy ל-API של Apigee וגם נקודות קצה שנוצרו באמצעות קריאות ל-API של TargetServer.

מגבלות התמיכה ב-Cache-Control

‫Apigee תומך בחלק מיכולות כותרת התגובה של Cache-Control שמוגדרות במפרט HTTP/1.1. חשוב לשים לב לדברים הבאים:

• ‫Apigee לא תומך בכותרות Cache-Control שמגיעות עם בקשות נכנסות של לקוחות.
• ‫Apigee תומך רק במושג של מטמון ציבורי. (לפי מפרט ה-HTTP, ‏ Cache-Control יכול להיות ציבורי (משותף) או פרטי (משתמש יחיד)).
• ‫Apigee תומך רק בחלק מההנחיות לתגובה של Cache-Control במפרט HTTP/1.1. פרטים נוספים זמינים במאמר בנושא תמיכה בהוראות של כותרת התגובה Cache-Control.

תמיכה בהנחיות של כותרת התגובה Cache-Control

‫Apigee תומך בהנחיות של קבוצת משנה מתוך מפרט HTTP/1.1 בתגובות משרתי מקור. בטבלה הבאה מפורטים הנחיות של כותרת תגובה של HTTP Cache-Control שנתמכות ב-Apigee.

מידע מפורט יותר על ההנחיות שמופיעות כאן זמין במאמר בנושא Cache-Control במפרט HTTP/1.1.

הוראה של Cache-Control	איך Apigee מעבד את ההנחיה
cache-extension	לא נתמך.
max-age	אם במדיניות ResponseCache הרכיב <UseResponseCacheHeaders> מוגדר לערך true, התשובה יכולה להיטמן במטמון למשך מספר השניות שצוין בהנחיה הזו. ההוראה הזו מבוטלת על ידי ההוראה s-maxage ומבטלת את הכותרת Expires. אפשר גם לבטל את ההגדרה הזו באמצעות הרכיב <ExpirySettings> של המדיניות. מידע נוסף מופיע במאמר בנושא מדיניות מטמון התגובות, בקטע <UseResponseCacheHeaders>, ובקטע בנושא הגדרת תפוגה של רשומת מטמון. הערה: תוכן שנשמר במטמון באמצעות מדיניות ResponseCache ישמור על הערך של max-age שהוגדר על ידי המקור שלו. המשמעות היא שכשהתוכן מאוחזר מהמטמון, יכול להיות שהוא ישן יותר מהערך של max-age (ישן יותר ממה שהלקוח יודע).
must-revalidate	לא נתמך. כל הערכים במטמון נמחקים על ידי Apigee ברגע שתוקף שלהם פג.
no-cache	מערכת Apigee שומרת במטמון את התגובה מהמקור, אבל צריך לאמת אותה מחדש מול שרת המקור לפני שמשתמשים בה כדי לספק מענה לבקשות לקוח עתידיות. הכלל הזה מאפשר למקור להחזיר תגובה מסוג 304 Not Modified כדי לציין שהתגובה צריכה להיות מוחזרת מהמטמון, וכך לחסוך את העיבוד שנדרש כדי להחזיר את התגובה כולה. אם שרת המקור מחזיר תגובה מלאה, הוא מחליף את רשומת המטמון הקיימת. המערכת מתעלמת מכל שמות השדות שמצוינים בהנחיה הזו. הערה: הכותרת HTTP/1.0,‏ Pragma: no-cache, נחשבת שוות ערך ל-Cache-Control: no-cache.
no-store	לא נתמך.
no-transform	לא נתמך.
private	לא נתמך. אם מתקבלת ההנחיה הזו, התגובה של המקור לא נשמרת במטמון. המערכת מתעלמת משמות של שדות.
proxy-revalidate	לא נתמך. כל הערכים במטמון נמחקים על ידי Apigee ברגע שתוקף שלהם פג.
public	מערכת Apigee שומרת במטמון את התגובה של המקור, גם אם הנחיות אחרות מציינות אחרת. לפי מפרט HTTP/1.1, היוצא מן הכלל היחיד לכלל הזה הוא אם התגובה כוללת כותרת הרשאה.
s-maxage	אם במדיניות ResponseCache הרכיב <UseResponseCacheHeaders> מוגדר לערך true, התשובה יכולה להיטמן במטמון למשך מספר השניות שצוין בהנחיה הזו. ההוראה הזו מבטלת את ההוראה max-age ואת הכותרת Expires. אפשר לבטל את ההגדרה הזו באמצעות הרכיב <ExpirySettings> במדיניות. מידע נוסף מופיע במאמר בנושא מדיניות מטמון התגובות, בקטע <UseResponseCacheHeaders>, ובקטע בנושא הגדרת תפוגה של רשומת מטמון. הערה: תוכן שנשמר במטמון באמצעות מדיניות ResponseCache ישמור על הערך s-maxage שהוגדר על ידי המקור שלו. המשמעות היא שכשהתוכן מאוחזר מהמטמון, יכול להיות שהוא ישן יותר מהערך של s-maxage (ישן יותר ממה שהלקוח יודע).

בתוקף עד

כשהדגל UseResponseCacheHeaders במדיניות ResponseCache מוגדר ל-true, ‏ Apigee יכול להשתמש בכותרת Expires כדי לקבוע את משך החיים (TTL) של רשומה במטמון. הכותרת הזו מציינת תאריך ושעה שאחריהם רשומה במטמון של תגובה נחשבת כרשומה לא עדכנית. הכותרת הזו מאפשרת לשרתים לסמן מתי אפשר להחזיר ערך ששמור במטמון על סמך חותמת זמן.

הערה: להנחיות הכותרת Cache-Control max-age ו-s-maxage יש קדימות על פני הכותרת Expires, והן מבטלות אותה. מידע נוסף מופיע במאמר בנושא הגדרת תפוגה של רשומת מטמון ובמאמר בנושא <UseResponseCacheHeaders> מדיניות מטמון התגובות.

פורמטים קבילים של תאריכים בכותרת Expires מתוארים במפרט HTTP/1.1. לדוגמה:

תאריך התפוגה: יום חמישי, 01 בדצמבר 1994 בשעה 16:00:00 לפי שעון GMT

מידע מפורט על פורמטים של תאריך/שעה ב-HTTP זמין בקטע Date/Time Formats במפרט HTTP/1.1.

הערה: בסעיף 14.21 של המפרט מצוין שערך Expires של יותר משנה בעתיד פירושו שרשומה במטמון לעולם לא תפוג. עם זאת, ב-Apigee הערך הזה מתפרש כמשמעות שהרשומה צריכה להישמר במטמון עד לתאריך ולשעה שצוינו.

מידע נוסף על הכותרת Expires מופיע בהגדרות של שדות כותרת במפרט HTTP/1.1.

ETag

תג ישות (ETag) הוא מזהה שמשויך למשאב שהתבקש. באמצעות ETag, שרת יכול לקבוע אם המשאב המבוקש והמשאב המשויך שנשמר במטמון זהים. לדוגמה, השרת יכול לשמור מחדש את התגובה במטמון אם היא לא תואמת למה ששמור כרגע במטמון. יכול להיות שהיא תחזיר את המשאב שנשמר במטמון אם תגי ה-ETag תואמים.

כשנקודת קצה יעד שולחת תגובה בחזרה ל-Apigee עם ETag, ‏ Apigee שומרת במטמון את ה-ETag יחד עם התגובה.

מידע נוסף על תגי ישות זמין בפרמטרים של פרוטוקול במפרט HTTP/1.1.

If-Match

בעזרת כותרת הבקשה If-Match, ישות שנשמרה במטמון היא עדכנית אם ה-ETag בכותרת תואם ל-ETag שנשמר במטמון. כל בקשה אחרת מלבד GET שמציינת כותרת If-Match מועברת לשרת מקורי כדי לוודא שלכל מתקני שמירה במטמון של המקור יש סיכוי לעבד את הבקשה.

מידע נוסף על If-Match מופיע בהגדרות של שדות כותרת במפרט HTTP/1.1.

אם Apigee מקבלת בקשת GET נכנסת מלקוח שכוללת כותרת If-Match:

אם	ואז
הכותרת If-Match מציינת תג ETag אחד או יותר	‫Apigee מאחזר רשומות במטמון שלא פג תוקפן עבור המשאב שצוין, ומשווה את תגי ה-ETag החזקים ברשומות האלה לאלה שצוינו בכותרת If-Match. אם נמצאת התאמה, המערכת מחזירה את רשומת המטמון. אם לא, הבקשה מועברת לשרת המקור.
הכותרת If-Match מציינת '*'	הבקשה מועברת לשרת המקור כדי לוודא שמתקני מטמון של מקור כלשהו יוכלו לעבד את הבקשה
נמצא רשומה במטמון עם אותו URI של הבקשה, אבל היא מכילה רק תגי ETags חלשים	צריך לאמת מחדש את הרשומה על ידי שרת המקור לפני שהיא מוחזרת ללקוח
תגי ה-ETag מגיעים מהשרת המקורי.	ה-ETag מוחזר ללקוח ללא שינוי

If-None-Match

עם הכותרת If-None-Match, ישות שנשמרה במטמון היא עדכנית אם ה-ETag בכותרת לא תואם ל-ETag שנשמר במטמון. בקשות אחרות מלבד GET שמכילות את הכותרת הזו מועברות לשרת המקור.

אם Apigee מקבל בקשת GET נכנסת עם הכותרת הזו:

אם	ואז
הכותרת If-None-Match מציינת תג ETag אחד או יותר	‫Apigee מאחזר רשומות במטמון שלא פג תוקפן עבור ה-URI שצוין, ומשווה בין תגי ה-ETag החזקים ברשומות האלה לבין אלה שצוינו בכותרת If-None-Match. אם נמצאת התאמה, Apigee מחזירה סטטוס 304 Not Modified. אם לא נמצאה התאמה, Apigee מעביר את הבקשה לשרת המקור.
הכותרת If-None-Match מציינת '*' וקיים במטמון ערך שלא פג תוקפו עבור מזהה ה-URI המבוקש	‫Apigee מחזירה את הסטטוס 304 Not Modified
נמצא רשומה במטמון עם אותו URI של הבקשה, אבל היא מכילה רק תגי ETags חלשים	צריך לאמת מחדש את הרשומה על ידי שרת המקור לפני ש-Apigee מחזיר אותה ללקוח
‫Apigee מקבל ETag משרת מקורי	ה-ETag מוחזר ללקוח ללא שינוי

If-Modified-Since

אם Apigee מקבל כותרת If-Modified-Since בבקשת GET, הכותרת מועברת לשרת המקור גם אם קיים ערך תקף במטמון.

כך אפשר לוודא שכל עדכון של משאב שלא עבר דרך Apigee יתועד. אם שרת המקור מחזיר ישות חדשה, Apigee מחליף את הערך הקיים במטמון בערך החדש. אם השרת מחזיר סטטוס 304 Not Modified, ‏ Apigee מחזיר את ערך התגובה אם הכותרת Last-Modified של התגובה שנשמרה במטמון מציינת שהיא לא השתנתה.

Accept-Encoding

כשבקשה נכנסת כוללת את הכותרת Accept-Encoding עם הערכים gzip, deflate או compress, שרת המקור מגיב עם נתונים דחוסים. כשמתקבלות בקשות נוספות בלי הכותרות Accept-Encoding, המערכת מצפה לתגובה לא דחוסה. מנגנון שמירת התגובות במטמון של Apigee יכול לשלוח תגובות דחוסות ולא דחוסות, בהתאם לכותרות הנכנסות, בלי לחזור לשרת המקור.

אפשר להוסיף ערכים של כותרת Accept למפתחות של מטמון כדי שהמפתחות יהיו משמעותיים יותר לכל פריט במטמון. פרטים נוספים מופיעים בקטע 'הגדרת מפתח מטמון' במאמר בנושא מדיניות מטמון תגובות.