נניח ששיניתם באתר של ספרייה את שעות הפתיחה להיום, אך חלק מהמבקרים עדיין רואים את השעות הישנות. תחילה יש להבחין בין כמה אפשרויות: תוכן המקור בשרת לא עודכן, הדפדפן השתמש שוב בתגובה ששמר, או שרת ביניים סיפק גרסה ישנה. טעינות חוזרות ונשנות של הדף אינן מספיקות כשלעצמן כדי לגלות באיזה שלב נמצאת הבעיה.
מטמון HTTP שומר תגובות שהתקבלו ומשתמש בהן שוב כאשר התנאים מתאימים. המאמר קושר בין הוראות השמירה והאימות של Cache-Control לבין ETag ותגובות 304, באמצעות דוגמה דמיונית של שעות פתיחה הפתוחות לציבור. חילופי ההודעות בהמשך קוצרו לצורך ההסבר; אלה אינם נתוני מדידה מספרייה אמיתית או משרת מסוים. המטרה היא להבין איזו תגובה אפשר להשתמש בה שוב ומתי, ולא להמליץ להסיר את כל המטמונים.
1. להפריד בין שמירה, בדיקה לפני שימוש ושיתוף
כדאי לקרוא את הוראות המטמון דרך שלוש שאלות נפרדות: האם מותר לשמור את התגובה, האם מותר להשתמש בה מיד בבקשה הבאה, והאם מותר לשתף אותה בין משתמשים. היתר לשמור אינו היתר להשתמש תמיד ללא בדיקה, ובדיקת עדכניות אינה קובעת עם מי מותר לשתף. RFC 9111 בנושא מטמון HTTP מבחין בין ההיבטים האלה. כאן נדון בהוראות תגובה ללא ארגומנטים נוספים המציינים שמות שדות.
| שאלה | הוראת תגובה קשורה | משמעות ההוראה |
|---|---|---|
| האם אסור לשמור? | no-store | מורה לא לשמור את התגובה לשימוש חוזר מאוחר יותר |
| האם יש לבדוק לפני שימוש חוזר? | no-cache | מאפשרת שמירה, אך מחייבת אימות מוצלח לפני שימוש חוזר |
| האם מותר לשתף בין משתמשים? | private | מונעת שמירה במטמון משותף; אינה אוסרת כל שמירה במטמון פרטי |
למשל, שעות פתיחה ציבוריות המשתנות לעיתים קרובות באותה כתובת עשויות לדרוש בדיקה לפני שימוש חוזר גם כאשר קיים עותק שמור. לעומת זאת, במסך אישי חשוב לברר גם את תנאי השיתוף בין משתמשים. private עוסקת במטמונים משותפים ואינה תחליף להתחברות או לבדיקת הרשאות גישה. איחוד הוראות בעלות מטרות שונות לכלל אחד עלול לשפר נתוני ביצועים ובו בזמן להציג תגובה לקהל הלא נכון.
כאשר מתעדים מדיניות, כתבו גם מדוע בחרתם בה. האם שעות הפתיחה הציבוריות משתנות? האם הלוגו הוא נכס קבוע? האם אותה כתובת מחזירה תוכן שונה לכל משתמש? אלה שאלות פתיחה לסיווג התגובות, ולא הגדרה אוניברסלית שאפשר להעתיק לכל שירות. חשוב לציין גם אם המדיניות חלה על הדפדפן, על CDN או על שכבת שמירה אחרת.
2. לא לבחור no-cache או no-store רק לפי השם
השם no-cache עשוי להישמע כאיסור שמירה, אך הכלל המרכזי שלו הוא אימות מחדש לפני שימוש חוזר. אפשר לשמור את התגובה ולהשתמש בגוף השמור אם השרת מאשר שלא השתנה. לעומת זאת, no-store מורה לא לשמור את התגובה. השאלה מה שומרים והשאלה מה בודקים בבקשה הבאה הן שאלות שונות, ולכן אין לצפות משתי ההוראות לאותה התנהגות.
גם המונח fresh דורש זהירות. משמעותו היא שהמדיניות מאפשרת להשתמש בתגובה שוב בלי אימות, ולא שמפעיל האתר טרם ערך את המקור. כאשר נקבע max-age, ייתכן שהמטמון ימשיך להחזיר תגובה ישנה עד תום התקופה המותרת גם לאחר שינוי המקור. יש להגדיר תחילה כמה זמן מותר שהעדכון יתעכב, ולא להציג זמן מטמון ארוך באופן שרירותי כפתרון ביצועים המתאים לכל סוג מידע.
מדריך מטמון HTTP של MDN מסביר גם מדוע אין לקרוא no-store חדש כאילו הוא מוחק עותק שכבר נשמר. תגובה חדשה עם no-store אינה מבטיחה מחיקת עותק קודם של אותה כתובת. אם העותק הישן עדיין מותר לשימוש חוזר ולא נשלחת בקשה, ההוראה החדשה כלל לא מגיעה אליו. לכן אין לראות בשינוי הזה פינוי מלא של המטמון או תנאי מספיק להגנת פרטיות. צריך לבדוק גם את משך החיים של העותקים הקודמים ואת דרך העדכון של מטמונים שבניהולכם.
3. לעקוב אחר ביקור חוזר בעזרת ETag ו־304
בדוגמה הדמיונית שלנו, /hours.json מחזיר שעת סגירה 18:00. הקטע הבא הוא דוגמת HTTP/1.1 מקוצרת ובה רק הכותרות הדרושות להסבר; פרטים אחרים הנדרשים בתקשורת אמיתית הושמטו. המחרוזת hours-v1 נבחרה כמזהה של הייצוג, ואינה נוסחה לחישוב זמן או ערך גיבוב שחושב מקובץ אמיתי.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}דפדפן ששמר את התגובה יכול לשלוח בביקור הבא בקשה מותנית עם מזהה ה־ETag בשדה If-None-Match. אם התנאי תואם לייצוג שהשרת היה בוחר כעת והייצוג לא השתנה, השרת יכול להחזיר 304 Not Modified. הקטע הבא מציג בקשה ולאחריה תגובה ברישום מקוצר; הוא אינו מציג גוף JSON חדש המצורף לתגובת 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"לפי הסבר ETag של MDN, הלקוח יכול להמשיך להשתמש בגוף השמור. תגובת 304 אינה כוללת גוף חדש, אך עדיין התקיימו בקשה ותקשורת לאימות. אם שעת הסגירה השתנתה ל־19:00 והייצוג השתנה, שליחת התנאי הישן אמורה להוביל לתגובת 200 עם גוף חדש ומזהה חדש. אין פירוש הדבר ש־no-cache מחזירה תמיד 304, או שהשרת אינו נדרש לבדוק את מסד הנתונים.
בדיקה מועילה בוחנת את הקשר בין התוכן למזהה, ולא רק את קוד המצב. אם הגוף משתנה אך השרת ממשיך לשלוח את ה־ETag הישן, האימות עלול לקבוע בטעות שלא חל שינוי. אם הגוף נשאר זהה והמזהה משתנה בכל פעם, ייתכן שיועברו יותר גופי תגובה מהנדרש. אלה שאלות על הקשר בין דרך יצירת התגובה בשרת לבין הייצוג שנבחר; עצם קיומה של כותרת ETag אינו מוכיח שהעדכון פועל נכון.
4. להבחין בין מסמך משתנה לנכס שקיבל שם חדש
אין הכרח להחיל אותה מדיניות על מסמך שמשתנה באותה כתובת ועל לוגו או סקריפט שמקבלים שם קובץ חדש בעת שינוי התוכן. במעבר מ־logo.a1.png ל־logo.b2.png, גם המסמך החדש צריך להפנות לכתובת החדשה. אם מוסיפים מזהה לשם הקובץ ואז מחליפים את תוכן הקובץ הישן, שוברים את ההבטחה שהכתובת מזהה תוכן קבוע.
העלאת הקובץ החדש לבדה אינה גורמת לכל המבקרים לבקש אותו מיד. אם מסמך ה־HTML שכבר הגיע לדפדפן עדיין מפנה לכתובת הלוגו הישן, הדפדפן עשוי להמשיך להשתמש בה. לכן יש לבדוק את מסלול עדכון המסמך לצד מדיניות המטמון של הנכסים. במקום לתת לכולם אותו משך שמירה, הגדירו בנפרד מהו עיכוב העדכון המותר לכל סוג תגובה.
בזמן פריסה עשויים להתקיים יחד מסמכים ישנים וחדשים. אם המסמך החדש נחשף לפני שהנכס שהוא מפנה אליו מוכן, או אם נכס ישן נמחק מוקדם מדי, נוצרים כשלים שונים. יש לוודא שהקבצים המוזכרים במסמך החדש כבר זמינים, ושכתובות שמסמכים ישנים עדיין מפנים אליהן נותרות נגישות. שינוי שמות הוא כלי מועיל, אך אינו פותר אוטומטית את סדר הפריסה ואת האפשרות לחזור לגרסה קודמת.
5. לבדוק השערה אחת בכל פעם בחלונית Network
תחילה תעדו מצב שבו הדפדפן רשאי להשתמש במטמון. רשמו את כתובת הבקשה המדויקת ואת מחרוזת השאילתה, את גרסת השעות הנראית במסך, את קוד המצב, את If-None-Match שבבקשה ואת Cache-Control ו־ETag שבתגובה. שמות כותרות דומים עלולים לטשטש מי שלח כל ערך, ולכן ציינו במפורש את צד הבקשה או התגובה. תיעוד חלונית Network של Chrome מראה כיצד לבדוק את המידע בלשונית Headers.
| מצב הבדיקה | מה כדאי לרשום | מסקנה חפוזה שיש להימנע ממנה |
|---|---|---|
| בקשה חוזרת לאותן שעות פתיחה | הבקשה המותנית, קוד המצב והשעות במסך | 304 פירושה אפס תקשורת |
| בקשה לאחר שינוי השעות הישנות | הגוף החדש, ETag וכתובת הבקשה בפועל | אם התקבלה הודעת שמירה מוצלחת במערכת הניהול, כל המשתמשים כבר קיבלו את העדכון |
| מטמון הדפדפן מושבת | ההבדל בין הורדה ראשונה לביקור חוזר רגיל | תוצאה זו מייצגת את ביצועי הביקור החוזר הרגיל |
| חזרה בעזרת כפתור אחורה | האם נשלחה בקשה חדשה והאם שוחזר מסך | אם המסך מוצג, בהכרח בוצע אימות HTTP חדש |
בצעו בנפרד בדיקה שבה מטמון הדפדפן מושבת. ב־Chrome האפשרות Disable cache חלה בזמן ש־DevTools פתוח, ולכן תעדו גם אם הכלים פתוחים וגם את מצב האפשרות. הבדיקה מועילה להבנת ההורדה הראשונה, אך אינה זהה לבדיקה של שימוש בעותק שמור בביקור חוזר רגיל. בלי תיעוד ההגדרה, הורדה חדשה בכל פעם עלולה להיראות בטעות כהוכחה שהמטמון אינו פועל. שמרו את תנאי הבדיקה כדי שתוכלו לחזור למצב המתיר מטמון ולהשוות.
קל יותר לצמצם את הסיבה כאשר לא מבצעים כמה שינויים ובקשות בבת אחת. תחילה בדקו ביקור חוזר בלי לשנות את התוכן, ואחר כך שנו פריט שעות אחד וצפו בהבדל בתגובה. שינוי בו־זמני של כתובת המסמך, הגדרות השרת ושם הקובץ מקשה לזהות מה גרם לתוצאה. אם התקבלה תגובה שונה מ־200 או מ־304 שציפיתם לה, קראו שוב את הבקשה והתגובה בפועל לפני הוספת הגדרות נוספות.
6. לבדוק גם שכבות שמירה אחרות ואת תנאי ההצלחה
השבתת מטמון HTTP בדפדפן אינה אומרת שה־CDN שלפני השרת או מסלולי שמירה אחרים ביישום נעלמו. אפשר לבדוק בנפרד אם service worker מטפל בבקשה, איזו תגובה שרת ביניים בוחר, ואם היישום ממשיך להציג נתונים שכבר קיבל. העובדה שאותה כתובת מופיעה אינה סיבה להניח שכל השכבות משתמשות באותו עותק.
גם לחיצה על אחורה דורשת בדיקה נפרדת מבקשת HTTP חדשה. כאשר הדפדפן משחזר מסך ממצב קודם של הגלישה, ייתכן שלא תראו בקשת אימות מחדש שציפיתם לה, גם אם התגובה כללה no-cache. הסקת מסקנה מיידית שהשרת התעלם מהכותרת עלולה להוביל לאבחון שגוי. תיעוד קיומה של בקשה בניווט חדש, בטעינה מחדש ובחזרה אחורה עוזר שלא לאחד תופעות שונות לבעיה אחת.
בדוגמת שעות הפתיחה, מדד ההצלחה אינו רק שיעור הפגיעות במטמון. צריך לבדוק שהעותק השמור משמש כראוי כשאין שינוי, שהמידע החדש מופיע בתוך הזמן המותר לאחר שינוי, ושהתגובה משותפת עם הקהל המתאים. רישום מועד השינוי, מועד התצפית, התנאים והגוף שהתקבל בפועל מקל על אדם אחר לשחזר את המצב. אם מדדי המהירות השתפרו אך שעות שגויות נשארות זמן רב, השינוי לא השיג את הדרישה המקורית.
לפני יישום בסביבת הייצור, בחנו יחד את המדיניות לכל סוג תגובה ואת נוהלי העדכון והחזרה לגרסה קודמת. אין להעתיק מדיניות מטמון של מסמך ציבורי לתגובה אישית, ואין לפרש אימות מוצלח כהשלמת בדיקת הרשאות גישה. הכותרות מוסרות כללים לשמירה ולשימוש חוזר. כאשר אפשר להסביר מה נשמר, אילו בדיקות נעשו ואיך התקבל המסך הנוכחי, אפשר לאבחן באופן מדויק יותר מדוע עדיין מוצג מידע ישן.