‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

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

סמל המטמון

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

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

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

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

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

תאריך התפוגה: יום חמישי, 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 תואמים.

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

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

If-Match

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

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

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

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

If-None-Match

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

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

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

If-Modified-Since

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

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

Accept-Encoding

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

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