# チームセッション 2021/06/26

## 参加メンバー
- kashiwagi
- sekikawa
- shintani
- nakano

## 今週の進捗

- 2-c
- 課題5の知識問題部分まで
- 来週は課題５実装部分まで（課題5終了）
- kashiwagi
- 課題5終わらせる
- sekikawa
- 課題６着手

- 2-b
- nakano
- 課題6の途中。明日PR出したい
- 来週はちょっと忙しそうな予感なので課題の進捗は出せないかも
- kimura
- 課題7キャッシュの実装中。
- 質問部分はちょっと自信ない
## クイズ（事前に共有あるとたすかります！）

## 困っていること、相談したいこと

- 課題5
- サードパーティ Cookie を用いて広告配信ネットワーク（例えばGoogle AdSense など）がどのようにユーザの訪問履歴を把握しているのか、説明してください
- みなさんの回答が気になります。良さげな資料とか見つけられてたら教えて欲しいです！

- 課題1-7
- キャッシュを残す処理をしているが、ブラウザ側のリクエストヘッダーは2回目以降のアクセスでも「cache-control : max-age:0」になる。こういうものなのかが気になります
- ちなみにステータスコードは下記のようにキャッシュを残すときと残さない時とで違うので、残っている気はする。
- キャッシュありの時のレスポンスのコード 304 Not Modified
- キャッシュなしの時のレスポンスコード 200 ok
- 以下はプラハの課題の中のスクショにもあったdockerのページです。こちらも同様
- 

## メンターセッションに向けて質問したいこと

## 来週の予定の確認

## メモ

- サーバーで生成すべきクッキーとフロントで生成すべきクッキー
- サーバー
- ログイン情報など。HTTP-Onlyが必須
- フロント
- サードパーティクッキーはこっち？フロントでJSから生成し、サードパーティのサーバーに送信する？
- 疑問点
- 課題5の実装部分で、ファーストパーティ、サードパーティともにHttp-Onlyをつけてサーバーからのレスポンスで設定する使い方はちょっと違う？
- ログイン情報などの、HTTPがステートレスだからステートを持たせたいという目的でセキュアな情報をcookieに保存するタイプの使い方はHttp-Only, サーバーから生成という使い方が正しいと思うが、サードパーティクッキーはフロントからJSで生成する方針がいいのでは？
- サードパーティクッキーはフロントで生成すべきじゃない？
- Http-Onlyなし、Same-Site: Noneで良さそう。別のサイトに送るためのものだから
- ニュースメディアに訪問した時、このようなクッキーがいくつか生成されていた

- なぜサードパーティクッキーも全てHttp-Onlyにしないのか？
- セキュリティより、フロントで生成するメリットを優先している？
　　- メリット: フロントからサイト内の行動を監視して、その行動履歴をフロントから自由にcookieに書き込めるのでは？
　　- サードパーティクッキー規制の抜け道を探すには、フロントのJSでの操作が必要？
　　- HTMLのデータ属性はJSからしか取れない？

- キャッシュの話

A request with max-age=0 indicates that a client requires a new response. The cache would forward the request to the origin server.
- リクエストの際に新しいレスポンスが欲しいと指定

A response header of max-age=3600 would be stored along with the response in any caches, and returned to the client. It would be compared against any future requests to determine whether this response is still fresh enough for that client.
- この応答がそのクライアントにとってまだ十分に新鮮であるかどうかを判断するために、将来の要求と比較されます。

- リクエストヘッダーのcache-controleとレスポンスヘッダーのcache-controleは役割が違う？
- リクエスト側
- ブラウザのキャッシュ制御の申告？
- -レスポンス側
- サーバー側の判断基準
- last-modifiedと絡んでくる？