セッションを実装しているとしましょう。
ブラウザがセッションCookieを表示するかどうかを確認します。はいの場合、Cookieを認証し、セッションが関連付けられているユーザーを見つけて、リクエストの処理に進みます。
セッションCookieが見つからない場合は、新しいセッションを作成し、後続のリクエストで受信する予定のブラウザにCookieを送信します。
さて、私の質問は、リクエストでセッションCookieを見つけた場合、レスポンスで同じCookieを再送信しますか。これはどのような状況で正しいですか？
注：Pyramidの実装はすべての応答で無条件にセッションCookieを送信するため、これをPyramid（Python）プログラマーとしてお願いします。（コードに移動）
通常、すべての応答にCookieを設定する必要はありません。ブラウザはすでにCookieを持っており、それがまだ有効である限り、サーバーに送信し続けます。
具体的には、PyramidセッションCookieには、通常のCookieの有効期限メカニズムとは別に有効期限が切れる署名およびタイムスタンプ付きのシークレットが含まれているため、すべてのリクエストに設定されます。Pyramidが埋め込まれたタイムスタンプを更新するたびに新しいCookieを設定して、セッションがまだ新鮮であることを示します。つまり、Cookieセットは毎回異なります。
セッションCookie（ブラウザのセッションCookieのように、クライアントが閉じられるとすぐに破棄される）の場合、私はおそらくこれを行いません。特に何も達成せず、このように繰り返し続けるのは帯域幅の無駄です（少量ではありますが）。
>ここにクッキーがあります。
<ありがとう！
>いいえ、実際にはクッキーを持っています。
<それは同じクッキーではありませんか？
>真剣に、このクッキーを持っています。
<やめてください。
あなたがそれについて何かを変えているときだけ、クッキーを再び送ることは意味があります。したがって、絶対有効期限のあるCookieの場合、その有効期限を頻繁に更新することをお勧めします。もちろん、Cookieに保存されている値を変更する場合は、ヘッダーも再度送信します。
私は一般的にPHP開発者であり、PHPネイティブセッションもこれを行います（毎回無条件に送信します）。この理由は、a）実装が簡単であり、b）有効期限を無視したり、クライアント側の永続ストレージへのCookieの書き込みに失敗したり、<他の奇数を挿入したりして、正常に動作していないユーザーエージェントを考慮しようとすることだと思います。ここでの動作>。
全員が2109/2965を適切に実装している場合、意味的に同一のCookieを複数回設定する理由はまったくありません。しかし、人々が実際に標準を読んだら、開発者の生活は退屈ではないでしょうか？
すべてがブラウザというわけではありません。分散システムでは、たとえば、あるノードからログインし、同じセッションを使用して他のノードからサービスにアクセスできます（1000のノードがある場合、各ノードからログインしたくない場合）ここで、ノードの1つが次のことに気付いたとします。 Cookieの有効期限が近づき、Cookieが更新されます。他のノードは変更を認識せず、Cookieを再度更新するか、古いCookieを使用します。いずれの場合も、複雑なノード間メッセージングを行わない限り、システム全体が機能しなくなります。その場合、JWTokenのようなものを実装できますが、それには独自の欠点（たとえば、ログアウトできない）があるため、常に受け入れられるとは限りません。そして、ブラウザ以外にjwtokensを理解していません。