Щоб відповісти на запитання про те, чому кешування працює, навіть якщо веб-сервер не містить заголовків:
- Термін дії:
[a date]
- Кеш-контроль: max-age =
[seconds]
Сервер люб'язно попросив будь-яких проміжних проксі-серверів не кешувати вміст (тобто елемент повинен кешуватися лише в приватному кеші, тобто лише на вашій локальній машині):
Але сервер забув включити будь-які підказки кешування:
- вони забули включити Expires , тому браузер знає, як використовувати кешовану копію до цієї дати
- вони забули включити Max-Age , тому браузер знає, наскільки довго кешований елемент хороший
- вони забули включити E-Tag , тому браузер може зробити умовний запит
Але вони включили у відповідь дату останньої зміни :
Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT
Оскільки браузер знає дату зміни файлу, він може виконати умовний запит . Він попросить сервер для файлу, але доручить серверу надсилати файл лише у тому випадку, якщо він був змінений з 2012/10/16 3:13:38:
GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT
Сервер отримує запит, розуміє, що у клієнта вже є остання версія. Замість того, щоб надсилати клієнта з 200 OKподальшим вмістом сторінки, натомість це говорить про те, що кешована версія хороша:
304 Not Modified
Ваш веб-переглядач повинен був зазнати затримки надсилання запиту на сервер і чекати відповіді, але це врятувало необхідність повторного завантаження статичного вмісту.
Чому Макс-Вік ? Чому термін дії закінчується ?
Тому що Last-Modified смокче.
Не всі на сервері має дату , пов'язану з ним. Якщо я будую сторінку на ходу, з нею не пов’язана дата - це зараз . Але я абсолютно готовий дозволити користувачу кешувати домашню сторінку на 15 секунд:
200 OK
Cache-Control: max-age=15
Якщо користувач забиває F5, він продовжує отримувати кешовану версію протягом 15 секунд. Якщо це корпоративний проксі, то всі 67198 користувачів, які потраплять на ту саму сторінку в тому ж 15-секундному вікні, отримають однаковий вміст - усі вони обслуговуються із близького кешу. Виграш ефективності для всіх.
Чеснота додавання Cache-Control: max-ageполягає в тому, що браузер навіть не повинен виконувати умовний запит.
- якщо ви вказали лише
Last-Modified, браузер повинен виконати запит If-Modified-Sinceі стежити за 304 Not Modifiedвідповіддю
- якщо ви вказали
max-age, веб-переглядачу навіть не доведеться страждати від обходу мережі; вміст вийде прямо з кеш-пам'яті
Різниця між "Кеш-контролем: максимальний вік" та "Закінчується"
Expiresє застарілим еквівалентом сучасного (c. 1998) Cache-Control: max-ageзаголовка:
Expires: Ви вказуєте дату (yuck)max-age: Ви вказуєте секунди (добро)І якщо вказано обидва , тоді браузер використовує max-age:
200 OK
Cache-Control: max-age=60
Expires: 20180403T192837
Будь-який веб-сайт, написаний після 1998 року, Expiresбільше не повинен використовувати , а замість цього використовувати max-age.
Що таке ETag?
ETag схожий на Last-Modified , за винятком того, що він не повинен бути датою - він просто повинен бути чимось .
Якщо я витягаю список продуктів із бази даних, сервер може надсилати останні rowversionяк ETag, а не як дата:
200 OK
ETag: "247986"
Моїм ETag може бути хеш SHA1 статичного ресурсу (наприклад, зображення, js, css, шрифту) або кешованої відображеної сторінки (тобто це робить вікі Mozilla MDN; вони мають хеш-кінцеву розмітку):
200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
І точно так само, як і у випадку із умовним запитом на основі Last-Modified :
GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT
304 Not Modified
Я можу виконати умовний запит на основі ETag:
GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
304 Not Modified
ETagПеревершує , Last-Modifiedтому що він працює для речей , крім файлів , або речей , які мають уявлення про дату . Це як раз є