私はこれに非常に混乱しています..私のWebアプリケーションは、ユーザーセッションを維持するためにJSESSIONID Cookieに依存するSpring Securityを使用しています。
私のページの 1 つで、同じドメインの別のページに 302 リダイレクトが行われますが、まだ http であり、https などに切り替えることはありません。何らかの理由で、ブラウザー (この場合は Chrome) が 2 番目の要求で Cookie を渡さず、ユーザーのセッションが失われます。
これは期待される http の動作ですか? 私はおそらく何かが欠けている..
明確にするために、Cookie はリダイレクトの前に既に設定されています。リダイレクトと同じ応答で Cookie を設定していません。
302 は Cookie を削除しないため、ホスト/ポートを変更しているか、サーバーで Cookie の有効期限が切れていると思われます。この 3 つのリクエスト (302 の前、302、302 の後) を見て、Expires 値を持つ Set-Cookie ヘッダーに関連するものを検索します。
Cookie パスに問題がある可能性があります。Cookie パスを「/」以外に設定すると、すべてのパスからアクセスできなくなります。
私自身の質問に答えます。投稿リクエストからリダイレクトする場合、303 (see other) レスポンスを使用する必要があることがわかりました。
RFC 2616 から
10.3.4 303 その他を参照
リクエストへのレスポンスは別の URI で見つけることができ、そのリソースで GET メソッドを使用して取得する必要があります。このメソッドは主に、POST でアクティブ化されたスクリプトの出力がユーザー エージェントを選択したリソースにリダイレクトできるようにするために存在します。新しい URI は、最初に要求されたリソースの代替参照ではありません。303 応答はキャッシュしてはなりませんが、2 番目の (リダイレクトされた) 要求に対する応答はキャッシュ可能かもしれません。