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

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

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

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