דף זה תורגם על ידי 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 של הכותרת תבטל הגדרות תפוגה אחרות במדיניות.

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

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