Частные и публичные в Cache-Control

127

Не могли бы вы описать пример, показывающий разницу между Public и Private Cache-Control в приложениях asp.net, размещенных в IIS.

Я читал в MSDN, что разница в следующем:

Public: устанавливает Cache-Control: public, чтобы указать, что ответ кэшируется клиентами и общими (прокси) кешами.

Частный: значение по умолчанию. Устанавливает Cache-Control: private, чтобы указать, что ответ кэшируется только на клиенте, а не через общие (прокси-сервер) кеши.

Я не уверен, что полностью понял плюсы и минусы каждого выбора. Было бы здорово привести пример того, когда его использовать или не использовать.

Например, что мне делать, если у меня есть два веб-сервера, на которых размещено одно и то же приложение? Есть ли на что обратить внимание, если я выберу частное или общедоступное?

— ppolyzos
источник

237

Единственная разница в том, что с Private вы не позволяете прокси кэшировать данные, которые проходят через них. В конце концов, все сводится к данным, содержащимся в отправляемых вами страницах / файлах.

Например, у вашего интернет-провайдера может быть невидимый прокси-сервер между вами и Интернетом, который кэширует веб-страницы для уменьшения необходимой пропускной способности и снижения затрат. Используя cache-control: private, вы указываете, что он не должен кэшировать страницу (но позволяет конечному пользователю делать это). Если вы используете cache-control: public, вы говорите, что все могут кэшировать страницу, и поэтому прокси будет хранить копию.

Как показывает практика, если это что-то, к чему может получить доступ каждый (например, логотип на этой странице), cache-control: public может быть лучше, потому что чем больше людей будут кэшировать это, тем меньше потребуется пропускная способность. Если это что-то, что связано с подключенным пользователем (например, HTML на этой странице включает мое имя пользователя, поэтому он не будет полезен никому), cache-control: private будет лучше, поскольку прокси будут кэшировать данные которые не будут запрашиваться другими пользователями, и они также могут хранить данные, которые вы не хотите хранить, на серверах, которым вы не доверяете.

И, конечно же, все, что не является публичным, должно иметь частный кеш. В противном случае данные могут храниться на промежуточном прокси-сервере, и к ним может получить доступ любой, кто имеет к ним доступ.

— salgiza
источник

Единственная разница в том, что с Private вы не позволяете прокси кэшировать ... Я предполагаю, что это была опечатка. +1 к ответу, кроме этого. Стоит добавить, что private не предлагает какой-либо степени безопасности, его все еще могут увидеть агенты в середине. Это просто означает, что ни один «честный» агент не даст его кому-нибудь вместо только что сгенерированного ответа.

— Джон Ханна,

Исправлена! Это забавно, потому что я перечитал это несколько раз перед тем, как опубликовать, но, полагаю, я знал, что здесь должно быть «не», поэтому мой разум просто добавил это: D. И да, +1 к вашему комментарию, потому что следует отметить, что, хотя и рекомендуется для данных, связанных с пользователем, приватность не заменяет истинную безопасность (SSL).

— salgiza

Так легко либо написать «не», когда не следует, либо опустить, когда нужно. Я знаю, что большое количество моих собственных правок (в разных полях) исправляет ту же опечатку.

— Джон Ханна

Итак, если мы ничего не укажем, будет ли поведение по умолчанию «общедоступным» или «частным»?

— Pacerier

@Honey, но может быть несколько клиентов, использующих один и тот же прокси. Если все в порядке, отправить всем клиентам один и тот же ответ, тогда можно кэшировать на уровне прокси, в противном случае можно кешировать на клиенте (все еще есть случаи, когда даже это плохая идея), но не на прокси.

— Джон Ханна