我對此非常困惑。我的web應用程序使用Spring Security，它依賴於JSESSIONID cookie來維護用戶會話。在302重定向到同一個域上的頁面後，Cookies未發送
我的一個網頁做了302重定向到另一個頁面上的同一個域，還是HTTP，沒有切換到HTTPS或任何幻想。出於某種原因，瀏覽器（在這種情況下，Chrome瀏覽器）沒有通過第二個請求的cookie並且用戶失去了他的會話。
這是預期的http行爲？我可能失去了一些東西..
只要是明確的，該Cookie已經重定向之前設置，我沒有設定爲重定向相同的響應中的Cookie。
回答我自己的問題。事實證明，從郵寄請求重定向時，必須使用303（另見）回覆。
從RFC 2616
10.3.4 303查看其它
於所述請求的響應可以根據不同的URI被發現和 應該使用該資源一GET方法來提取。此方法 主要用於允許POST激活的腳本輸出到 將用戶代理重定向到選定的資源。新的URI不是最初請求的資源的替代引用 。響應不得被緩存，但對第二個 （重定向）請求的響應可能是可緩存的。
302不會刪除任何Cookie，所以我認爲你正在改變主機/端口或服務器到期的cookie。查看這3個請求（在302,302之前，302之後），並搜索與Set-Cookie頭相關的內容並帶有expires值。
這可能是你有問題的Cookie路徑，如果你設置cookie路徑，以「/」不同的東西，這將是所有路徑不可訪問。
這可能是瀏覽器的錯誤。參見Chromium bug＃696204。在我的情況下，解決方法是將SameSite=Strict更改爲Lax。
使用303而不是302修復了您的cookie問題？似乎很奇怪。如果cookie域和路徑設置正常，則302不應阻止cookie的使用。 – regilero
我的（模糊的）理解是，在302重定向（post => get）過程中改變http方法時，規範有點含糊不清，並且添加了303狀態代碼來排除這種不明確性。雖然我可能會說出我的屁股，所以請隨時糾正我。 – Kimble
（重定向）響應中使用的狀態代碼不可能與瀏覽器在以下請求中發送的cookie有任何關係，特別是如果「cookie已在重定向之前設置」。瀏覽器發送的請求（由於以前的重定向響應）與來自瀏覽器的任何其他請求相同，因此應該發送任何_valid_ cookie。 – MrWhite