if-Modified-Since vs if-None-match

Яка може бути різниця між if-modified-since та if-none-match? У мене відчуття, що if-none-match використовується для файлів, тоді як if-modified-since використовується для сторінок?

Щодо відмінностей між Last-Modified/If-Modified-Sinceта ETag/If-None-Match:

І те, і інше можна використовувати як взаємозамінні. Однак залежно від типу ресурсу та того, як він генерується на сервері, на той чи інший питання ("чи було це змінено з ...?" / "Чи все-таки це відповідає цьому ETag?") Може бути простіше відповісти .

Приклади:

• Якщо ви обслуговуєте файли, використання файлів mtimeяк Last-Modifiedдати є найпростішим рішенням.
• Якщо ви обслуговуєте динамічну веб-сторінку, побудовану на основі кількох запитів SQL, перевірка, чи не змінилися дані, повернені будь-яким із цих запитів, може бути недоцільною (якщо всі вони не мають якогось стовпця "останньої зміни"). У цьому випадку використовувати, наприклад, хеш md5 вмісту сторінки, оскільки це ETagбуде набагато простіше.
  OTOH, це означає, що вам все одно доведеться створити цілу сторінку на сервері, навіть для умовного GET. Визначення того, що саме має входити в ETag (первинні ключі, номери редакцій, ... тощо), може заощадити тут багато часу.

Детальніше про тему дивіться за цими посиланнями:

• http://www.tbray.org/ongoing/When/200x/2008/08/14/Rails-ETags
• http://bitworking.org/news/150/REST-Tip-Deep-etags-give-you-more-benefits

If-Modified-Sinceпорівняно з Last-Modifiedтоді If-None-Matchяк порівняно з ETag. І те, Modified-Sinceі ETagінше можна використовувати для ідентифікації конкретного варіанту ресурсу.

Але порівняння If-Modified-Sinceз Last-Modifiedдає вам інформацію , чи знаходиться в кеші варіант старше або новіший , тоді як порівняння , If-None-Matchщоб ETagпросто дає інформацію про те , як є ідентичними чи ні. Крім того, більшість ETagгенераторів включають інформацію про специфічний для системи inode, тому переміщення файлу на інший диск також може змінити ETag.

Значення часової позначки, яке використовується в Last-Modified / If-Modified-Since, має обмежену точність - одну секунду, і цього просто недостатньо для швидкого зміни вмісту, наприклад, наприклад, програми веб-чату, де в будь-яку секунду можна опублікувати більше одного повідомлення . ETag / If-None-Match може допомогти вирішити цю проблему.

Як зазначено в найкращих практиках Google:

Важливо вказати один із Expires або Cache-Control max-age та один з Last-Modified або ETag для всіх кешованих ресурсів. Зайвим є вказувати як Expires, так і Керування кешем: max-age, або вказувати Last-Modified та ETag.

https://developers.google.com/speed/docs/best-practices/caching

If-Modified-Since використовує дату, тоді як If-None-Match використовує ETag . Вони можуть використовуватися як для "сторінок" (тобто HTML), так і для інших файлів.

Якщо сервер не визначив його слабким, ETag вважається потужним валідатором і, отже, може використовуватися для задоволення запиту умовного діапазону. Однак більшість автоматично генерованих тегів ET мають труднощі у ситуаціях ферми серверів, оскільки вони часто використовують інформацію inode та / або унікальний стійкий лічильник. На практиці я виявив, що останньо змінений заголовок достатній для досить статичного вмісту, наприклад, для обслуговування захищеного статичного вмісту, оскільки час запису файлу робить досить хороший валідатор.

ETag на сьогоднішній день є найбільш гнучким. Клієнти, що відповідають вимогам, повинні надіслати ETag в умовному запиті, тоді як вони ПОВИННІ надіслати обидва, якщо такі є.

Заголовок If-Modified-Since використовується, щоб вказати час, коли браузер востаннє отримав запитуваний ресурс. Заголовок If-None-Match використовується для вказівки тегу сутності, який сервер видав із запитуваним ресурсом під час останнього отримання.

Описаними двома способами ці заголовки використовуються для підтримки кешування вмісту в браузері, і вони дозволяють серверу вказувати браузеру використовувати кешовану копію ресурсу, а не відповідати повним вмістом ресурсу, якщо це не обов `язково.