תמיכה בכותרות של תגובת 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 גם בבקשות של לקוחות וגם בתגובות של שרתי מקור). שרתי מקור יכולים לכלול גם נקודות קצה של יעד שהוגדרו ב-Apigee API proxy וגם נקודות קצה שנוצרו באמצעות קריאות ל-TargetServer API.

מגבלות התמיכה ב-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 בתגובות משרתי מקור. בטבלה הבאה מפורטות ההנחיות של כותרת התגובה Cache-Control ב-HTTP שנתמכות ב-Apigee.

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

הוראה של 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, היוצא מן הכלל היחיד לכלל הזה הוא אם התגובה כוללת כותרת Authorization.
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 למפתחות של מטמון כדי שהמפתחות יהיו משמעותיים יותר לכל פריט במטמון. פרטים נוספים מופיעים בקטע 'הגדרת מפתח מטמון' במאמר בנושא מדיניות מטמון התגובות.