HTTPヘッダー「Cache-Control：public」を持つリスクは何ですか？
_Cache-Control_ HTTP/1.1ヘッダーは、max-ageと、キャッシュコンテンツをパブリックにするかプライベートにするかを指定でき、中間キャッシュがコンテンツをキャッシュできるかどうかを示します。
たとえば、Ruby on Railsのexpires_in()はデフォルトで_Cache-Control: private_を使用します
公開するリスクは何ですか？パブリックの場合、コンテンツをキャッシュできる余分な場所はどれですか？たとえば、プロキシサーバーでしょうか？
ウェブサイトがAmazon.comに似ているが、ユーザーが匿名の場合、プライバシーの問題はおそらくないでしょうか？ユーザーがログインしている場合、データは場所を通過し、データが表示されるため、プライバシーの問題が発生する可能性があります。その場所が「不良」になりたい場合は、とにかく_Cache-Control: private_を気にする必要はありません。
ユーザーがログインできるWebサイトであるが、魚油やビタミンなどの健康製品のみを検索する場合はどうでしょう。その場合、ユーザーがプライバシーの問題をもっと気にかけることができる本などの製品の種類がはるかに多いAmazon.comとは異なるため、プライバシーはさらに低下します。
そうは言っても、_Cache-Control: public_を持つことの追加の利点は何ですか？
Cache-Control: Publicの問題は、応答がキャッシュされて別のユーザーに表示される可能性があることです。これは、プライベートデータを表示している認証済みアプリケーションがある場合に問題です。一般に、パブリックを使用するのは静的ページ、またはどのユーザーがリクエストを行っていても同じデータを返すページに対してのみ使用する必要があります。
さらに、次の仕様を見つけました。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
public
通常、非キャッシュまたは非共有キャッシュ内でのみキャッシュ可能である場合でも、応答が任意のキャッシュによってキャッシュされる場合があることを示します。 （追加の詳細については、承認、セクション14.8も参照してください。）
プライベート
応答メッセージのすべてまたは一部が単一のユーザー向けであり、共有キャッシュによってキャッシュされてはならないことを示します。これにより、Originサーバーは、応答の指定された部分が1人のユーザーのみを対象としており、他のユーザーによるリクエストに対する有効な応答ではないことを示すことができます。プライベート（非共有）キャッシュは、応答をキャッシュしてもよい（MAY）。注：このWordプライベートの使用は、応答がキャッシュされる場所のみを制御し、メッセージコンテンツのプライバシーを保証することはできません。
したがって、中間キャッシュではなく「共有キャッシュ」に近いように見えます。