Різниця між заголовками Pragma та Cache-Control?


166

Я читав про заголовок Прагми у Вікіпедії, який говорить:

"Поле заголовка Pragma: no-cache - це заголовок HTTP / 1.0, призначений для використання в запитах. Це браузер, який повідомляє серверу та будь-яким проміжним кешам, що він хоче свіжу версію ресурсу, а не для сервера. щоб сказати браузеру не кешувати ресурс. Деякі агенти користувачів звертають увагу на цей заголовок у відповідях, але HTTP / 1.1 RFC спеціально застерігає від покладання на цю поведінку ".

Але я не зрозумів, що це робить? Яка різниця між Cache-Controlзаголовком, значення якого є no-cacheі Pragmaзначення якого також no-cache?

Відповіді:


196

Pragmaє реалізацією HTTP / 1.0 і cache-controlє реалізацією тієї ж концепції HTTP / 1.1. Вони обидва покликані запобігти кешуванню відповіді клієнта. Старі клієнти можуть не підтримувати HTTP / 1.1, тому цей заголовок все ще використовується.


31
Хоча відповідь cnst нижче набагато складніша, вона також набагато правильніша відповідно до специфікації. Pragma: no-cacheпризначений для використання лише у запитах (означає "Я хочу оригінал, а не кешовану копію"), а його поведінка не вказана для відповідей.
clime

5
Cache-Control: no-cacheмає те саме значення для запитів, але насправді також визначено для відповідей, тобто "Якщо ви хочете використовувати кешовану копію цього в майбутньому, спершу потрібно перевірити, чи він є оновленим (тобто виконати повторну перевірку)".
clime

3
Це для кеш-керування, він не повинен бути ТІЛЬКИ для запобігання кешу, він також може бути використаний, щоб сказати "Ви можете кешувати це". ....
jave.web

Основна відповідь. Щоб зробити це складніше: це також заголовок запиту, що означає, що ви можете надсилати без кешу і на сервер. І що насправді може означати повернення застарілого контенту клієнтам, ЩО ?? Тепер ви це забули і прочитали вищезгадану просту відповідь і насолоджуйтесь своїм життям, не копайте її занадто важко,
хаха

Вони обидва покликані запобігти кешуванню відповіді клієнтом - заплутану ноту для читачів. Він також може мати те, max-ageщо не перешкоджає кешування. Він просто встановлює термін придатності для цього ...
Мед,

97

Немає різниці, за винятком того, що Pragmaвін визначається лише як застосовний до запитів клієнта, тоді як Cache-Controlможе використовуватися як запитами клієнтів, так і відповідями серверів.

Отже, що стосується стандартів, їх можна порівняти лише з точки зору клієнта, який робить запит, і сервера, який отримує запит від клієнта. Http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32 визначає сценарій наступним чином :

HTTP / 1.1 кеші ДОЛЖЕН би ставитись до "Pragma: no-cache" так, ніби клієнт надіслав "Cache-Control: no-cache". Жодні нові директиви Pragma не будуть визначені в HTTP.

  Note: because the meaning of "Pragma: no-cache as a response
  header field is not actually specified, it does not provide a
  reliable replacement for "Cache-Control: no-cache" in a response

Як я читав вище:

  • якщо ви пишете клієнта і вам потрібно no-cache:

    • просто використовуйте Pragma: no-cacheу своїх запитах, оскільки ви можете не знати, чи Cache-Controlпідтримується він сервером;
    • але у відповідях, щоб вирішити, чи потрібно кешувати, перевірити Cache-Control
  • якщо ви пишете сервер:

    • при розборі запитів від клієнтів перевіряйте Cache-Control; якщо його не знайдено, перевірте Pragma: no-cacheта виконайте Cache-Control: no-cacheлогіку;
    • у відповідях надайте Cache-Control.

Звичайно, реальність може відрізнятися від того, що написано чи мається на увазі в RFC!


5
Що робити, якщо в заголовку є обидва? Cache-Control: max-age=86400і Pragma: no-cache? Який із них буде вшановуватися сучасними браузерами?
PKHunter

3
@PKHunter, чому б ти дбав, яким шляхом він рухається, якщо поведінка не визначена? Якщо ви несете відповідальність за сервер, очевидно, ви можете зробити краще, ніж видавати клієнту оманливу інформацію. Крім того, як було зазначено у моїй відповіді, значення Pragma: no-cacheвизначається лише для запитів від браузера, і таким чином воно буде абсолютно недійсним і не визначеним у відповідях із сервера на браузер, наприклад, я б уявив, що кожен браузер (будь то сучасний чи не) повинен ігнорувати такий заголовок у будь-якій відповіді, яку він може отримати.
cnst

3
Сучасний браузер повинен ігнорувати Прагму на користь кеш-контролю, якщо вони є обома, оскільки останні можуть визначати часові періоди та іншу інформацію, яка не була доступна в початковому протоколі 1.0.
Рандалл Борк

17
| Stop using          | Replaced with                    |
| (HTTP 1.0)          | (HTTP 1.1 - 1999)                |
|---------------------|----------------------------------|
| Expires: [date]     | Cache-Control: max-age=[seconds] |
| Pragma: no-cache    | Cache-Control: no-cache          |

Якщо це після 1999 року, а ви все ще використовуєте Expires або Pragma , ви робите це неправильно.

Я дивлюся на тебе Stackoverflow:

200 OK
Pragma: no-cache
Content-Type: application/json
X-Frame-Options: SAMEORIGIN
X-Request-Guid: a3433194-4a03-4206-91ea-6a40f9bfd824
Strict-Transport-Security: max-age=15552000
Content-Length: 54
Accept-Ranges: bytes
Date: Tue, 03 Apr 2018 19:03:12 GMT
Via: 1.1 varnish
Connection: keep-alive
X-Served-By: cache-yyz8333-YYZ
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1522782193.766958,VS0,VE30
Vary: Fastly-SSL
X-DNS-Prefetch-Control: off
Cache-Control: private

tl; dr: Pragmaспадщина HTTP / 1.0 і не потрібна з Internet Explorer 5 або Netscape 4.7. Якщо ви не очікуєте, що деякі з ваших користувачів будуть використовувати IE5: безпечно припинити його використання.


  • Закінчується: [date] (застаріло - HTTP 1.0)
  • Прагма: без кешу (застаріле - HTTP 1.0)
  • Кеш-контроль: max-age =[seconds]
  • Кеш-контроль: без кешу (повинен щоразу повторно перевіряти кешовану копію)

І умовні запити:

  • Умовні запити, засновані на позначці (тег об'єкта)
    • Сервер: Etag: W/“1d2e7–1648e509289”
    • Клієнт: If-None-Match: W/“1d2e7–1648e509289”
    • Сервер: 304 Not Modified
  • Змінено умовні запити на дату
    • Сервер: last-modified: Thu, 09 May 2019 19:15:47 GMT
    • Клієнт: If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT
    • Сервер: 304 Not Modified

остання зміна: Чт, 09 травня 2019 19:15:47 GMT


2
RFC каже, що ви повинні використовувати їх як у випадку, якщо клієнт не підтримує кеш-контроль: tools.ietf.org/html/rfc7234#page-29
Рандалл Борк,

3
Клієнт «повинен» включати в себе як - якщо він не хоче , щоб обробити HTTP - сервера / 1.1 і HTTP / 1.0 кешування по- різному. Сервер взагалі не повинен включати Pragma. (У HTTP / 1.0 Pragma був визначений як розширюване поле для визначених реалізацією директив для одержувачів. Ця специфікація знімає такі розширення для поліпшення сумісності.)
Ian Boyd,

2
З точки зору безпеки, рекомендується використовувати його. Багато браузерів дотримуються директиви pragma: no-cache, тому рекомендується використовувати її OWASP
Рандалл Борк

2
@RandallBorck: Ви поширюєте застарілу (не менше двох десятиліть!) Інформацію. Більше браузерів не дотримується директиви Pragma, якщо це не 1999 рік. Це рада з культових вантажів: "Це не шкодить, і ми завжди це робили, тому це добре і потрібно".
Пісквор вийшов з будівлі

2
@Piskvor Більшість серверів все ще підтримують і 1.0, і 1.1, тому, якщо активно не блокувати запити HTTP / 1.0, ви не обираєте, який протокол використовує клієнт. Більшість розробників сьогодні не намагаються блокувати 1,0, отже, це все ще найкраща практика навіть у 2019 році.
Рандалл Борк
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.