cache-controlТема є основним механізмом для сервера HTTP , щоб сказати кешуючий проксі - сервера «свіжість» у відповідь. (тобто, як / якщо довго зберігати відповідь у кеші)
У деяких ситуаціях cache-controlдиректив недостатньо. Дискусія робочої групи HTTP архівується тут, описуючи сторінку, яка змінюється лише залежно від мови. Це не правильний варіант використання заголовка варіації, але контекст цінний для нашого обговорення. (Хоча я вважаю, що заголовок Vary у такому випадку вирішить проблему, існує кращий спосіб.) З цієї сторінки:
Vary суворо для тих випадків, коли проксі-сервіс безглуздо або надмірно ускладнює реплікацію того, що робив би сервер.
Надуманий приклад:
Ваш HTTP-сервер має велику цільову сторінку. У вас є дві трохи різні сторінки з однаковою URL-адресою, залежно від того, чи користувач був там раніше. Ви розрізняєте запити та "кількість відвідувань" користувача на основі файлів cookie. Але - оскільки цільова сторінка вашого сервера настільки велика, ви хочете, щоб посередники-проксі, якщо це можливо, кешували відповідь.
Заголовків URL, Last-Modified та Cache-Control недостатньо, щоб дати це розуміння проксі-серверу кешування, але якщо ви додасте Vary: Cookie, механізм кешування додасть заголовок Cookie до своїх рішень щодо кешування.
Нарешті, для невеликого трафіку, динамічних веб-сайтів - я завжди знаходив просте Cache-Control: no-cache, no-storeі Pragma: no-cacheдостатнє.
Редагувати - щоб точніше відповісти на ваше запитання: заголовок запиту HTTP "Прийняти" визначає типи вмісту, які клієнт може обробити. Якщо у вас є дві копії одного вмісту за однією URL-адресою, які відрізняються лише типом вмісту, тоді використання Vary: Acceptможе бути доречним.
Оновлення 11 вересня 12:
Я включаю пару посилань, які з’явились у коментарях, оскільки цей коментар був спочатку опублікований. Вони обидва чудові ресурси для реальних прикладів (і проблем) із Vary: Accept; Якщо ви читаєте цю відповідь, вам також потрібно прочитати ці посилання.
Перший із видатних EricLaw про поведінку Internet Explorer із заголовком Vary та деякі проблеми, які він створює для розробників: Vary Header запобігає кешуванню в IE . Коротше кажучи, IE (до IE9) не кешує будь-який вміст, який використовує заголовок Vary, оскільки кеш запиту не включає заголовки HTTP-запиту. EricLaw (Ерік Лоуренс у реальному світі) - менеджер програм у команді IE.
Другий - від Ерана Медана, і це поточне обговорення несподіваної поведінки, пов’язаної з Vary в Chrome: резервне копіювання неправильно обробляє заголовок Vary . Це пов’язано з поведінкою IE, за винятком того, що розробники Chrome застосували інший підхід - хоча, схоже, це не був навмисний вибір.