私はこれについて自分で少しテストを行いました（正確にはDWRフレームワークAjaxリクエストハンドラーのサーバー側処理中）。Cookieを正常に操作できるようですが、これは私が読んだAjaxのベストプラクティスとブラウザーが XmlHttpRequest からの応答を解釈する方法。私がテストしたことに注意してください：
すべての場合において、Ajax リクエスト処理中の HttpServletResponse オブジェクトに対する標準の Cookie 操作はブラウザーによって正しく解釈されましたが、Cookie 操作をクライアント側にプッシュするのがベスト プラクティスなのか、それともこの (はるかにクリーンな) サーバーがサイド Cookie の処理は信頼できます。
DWR フレームワークと Ajax 全般に固有の回答を歓迎します。
XMLHttpRequest は、常に Web ブラウザの接続フレームワークを使用します。これは、XHR オブジェクトがブラウザーの Cookie プールにアクセスできない場合にユーザーがログアウトされるため、AJAX プログラムが正しく機能するための要件です。
理論的には、Web ブラウザーがブラウザーの接続フレームワークを使用せずにセッション Cookie を共有することは可能ですが、これは (私の知る限り) 実際には起こりませんでした。Flash プラグインでさえ、Web ブラウザの接続を使用します。
したがって、最終的には、AJAX を介して Cookie を操作しても安全です。AJAX呼び出しが発生しない可能性があることに注意してください。これらは保証されたイベントではないため、当てにしないでください。
DWR のコンテキストでは、「安全」ではない可能性があります。
DWRサイトを読むと、次のように書かれています：
HTTP 要求と応答を読み取り専用として扱うことが重要です。HTTP ヘッダーは問題なく通過する可能性がありますが、一部のブラウザーがそれらを無視する可能性は十分にあります。
これは、Cookie やリクエスト属性を設定することは禁止されていることを意味します。
そうは言っても、リクエスト属性を設定するコード (そのページを読む前に書いたコード) があり、正常に動作しているように見えます (上記のコメントで言及した Cookie の削除は別として)。
クライアント側で Cookie を操作することは、「ベスト プラクティス」とは正反対です。また、それも必要ないはずです。HttpOnly Cookie が導入されたのは無駄ではありません。