HTTP-заголовки: управление кешем и механизмом истории

Я пытаюсь определить лучшие HTTP-заголовки для отправки для четырех вариантов использования . Я надеюсь придумать заголовки, которые не зависят от сниффинга версии пользовательского агента / протокола, но я соглашусь с этим, если ничего не подходит. Все URL-адреса загружаются через полностью настраиваемый обработчик, поэтому я могу выбирать все заголовки, как мне нравится, это все о промежуточных прокси и пользовательских агентах . Если возможно, это должно быть совместимо с клиентами HTTP / 1.0 и HTTP / 1.1. Если существует несколько решений, лучшее из них будет самым коротким при передаче по сети.

Статическое общедоступное содержимое

Весь «Статический общедоступный контент» - это то, о чем на самом деле идет HTTP: если URL-адрес тот же, содержание то же самое. Я могу сделать это легко: например, я помещаю значок профиля пользователя в http://domain.com/profiles/xyz/icon/1234abcd , где «1234abcd» - это SHA-1 содержимого файла значок. Если я перейду на значок в будущем, я создам новый URL-адрес и изменю все существующие источники перехода, которые должны использовать новый значок. Каковы лучшие заголовки, чтобы объявить, что это может быть кешировано навсегда и может быть использовано совместно? В настоящее время я думаю примерно так:

Date: 
Expires: 

Достаточно ли этого, чтобы разрешить кэширование пользовательскими агентами и прокси? Нужен ли мне Last-Modified или Pragma ?

Статический непубличный контент

Весь «Статический непубличный контент» статичен, но может быть недоступен всем. Фактически, этот контент будет доступен только выбранным пользователям, вошедшим в систему (сеанс сохраняется с помощью файла cookie сеанса, содержащего UUID сеанса). Если URL-адрес такой же, то и содержание такое же. Однако ответ не является публичным. Примером использования может быть изображение, предоставленное избранным друзьям в социальной сети. В настоящее время я думаю примерно так:

Date: 
Expires: 
Cache-Control: private, max-age=, s-maxage=0

Достаточно ли этого, чтобы разрешить кеширование пользовательскими агентами и отключить прокси? Нужна ли мне Pragma ?

Неустойчивый общедоступный контент

Весь «Неустойчивый общедоступный контент» является непостоянным и доступным для всех. Что-то вроде главной страницы http://slashdot.org/ без входа в систему. Цель состоит в том, чтобы разрешить быстрое обновление содержимого в неизменяемом URL-адресе. Обратите внимание, что я НЕ хочу нарушать механизм истории пользовательского агента (то есть, щелкнув что-нибудь на изменчивой странице, а затем нажав кнопку «Назад», это не должно привести к получению изменчивой страницы с сервера - однако, щелкнув ссылку, ведущую на главную страницу, вы должны получить ресурс с сервера). В настоящее время я думаю о чем-то вроде:

Date: 
Expires: 
Cache-Control: public, max-age=0, s-maxage=0

Достаточно ли этого, чтобы предотвратить кеширование, но разрешить механизм истории (кнопка возврата)? Я знаю, что если я отправлю Cache-Control: no-store, must-revalidate , я могу принудительно перезагрузить компьютер, но это не то, что я хочу, потому что это тоже сломает кнопку возврата. Нужен ли мне Last-Modified или Pragma ?

Несмотря на то, что это общедоступно, вероятно, нет смысла разрешать промежуточным прокси-серверам кэшировать его, потому что он непостоянен.

Неустойчивый непубличный контент

Весь «Неустойчивый непубличный контент» является непостоянным и недоступным для всех (частным) материалом. Что-то вроде главной страницы http://slashdot.org/ , когда вы вошли в систему. Цель состоит в том, чтобы разрешить быстрое обновление содержимого в неизменяемом URL. Обратите внимание, что я НЕ хочу нарушать механизм истории пользовательского агента (то есть щелчок чего-либо на изменчивой странице и последующее нажатие кнопки возврата не должно приводить к получению изменчивой страницы с сервера - однако, щелкнув ссылку, ведущую на главную страницу, вы должны получить ресурс с сервера). В настоящее время я думаю что-то вроде:

Date: 
Expires: 
Cache-Control: private, max-age=0, s-maxage=0

Достаточно ли этого, чтобы предотвратить кеширование, но разрешить механизм истории (кнопка возврата)? Нужна ли мне Pragma ?

Вещи, которые все еще нуждаются в тестировании с предложенными мной заголовками:

• Убедитесь, что частный контент не будет просочен через прокси HTTP / 1.0.
• Убедитесь, что кеширование работает правильно в прокси.
• Убедитесь, что кэширование работает правильно в пользовательских агентах.
• Убедитесь, что механизм истории пользовательского агента работает в пользовательских агентах (во всех случаях).
• Убедитесь, что переход по ссылке на изменчивую страницу приводит к получению свежего содержимого с сервера .
• Проверять все результаты при использовании HTTPS вместо HTTP.