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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

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

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

בקרת מטמון

ב-Apigee Edge יש תמיכה בכותרת Cache-Control רק בתגובות שהוחזרו משרתי מקור לקצה העורפי (המפרט HTTP/1.1 מאפשר שימוש בכותרות Cache-Control גם בבקשות לקוח וגם בתגובות של שרת המקור). שרתי מקור יכולים לכלול גם נקודות קצה של יעד שמוגדרות בשרת 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 לגבי תגובות משרתי מקור. בטבלה הבאה מתוארים התמיכה של 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> במדיניות בנושא מטמון תגובה.
must-revalidate ההודעה לא נתמכת. כל הרשומות מהמטמון נמחקות על ידי Apigee Edge מיד כשהתוקף שלהן פג.
no-cache

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

בתוקף עד

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

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

בתוקף עד: ה', 1 בדצמבר 1994 בשעה 16:00:00 לפי שעון גריניץ'

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

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

ETag

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

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

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

אם יש התאמה

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

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

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

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

אם-ללא-התאמה

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

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

אם Then
הכותרת If-None-Match מציינת ETags אחד או יותר
  1. ב-Apigee Edge מאחזרים כל ערכי מטמון שעדיין בתוקף עבור ה-URI שצוין, ומשווה כל תג ETags חזקים ברשומות שנשמרו במטמון לבין אלה שצוינו בכותרת If-None-Match.
  2. אם תימצא התאמה, Edge יחזיר את הסטטוס '304 לא השתנה'. אם לא נמצאה התאמה, Edge מעביר את הבקשה לשרת המקור.

הכותרת If-None-Match מציינת '*' וקיימת רשומה שמורה במטמון עבור ה-URI המבוקש

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

אם השתנה מאז

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

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

קבלה-קידוד

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

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