I'm very confused by this.. My web application uses Spring Security which relies upon a JSESSIONID cookie to maintain a users session.
One of my pages does a 302 redirect to another page on the same domain, still http, not switching to https or anything fancy. For some reason the browser (Chrome in this case) does not pass the cookie with the second request and the user looses his session.
Is this the expected http behavior? I'm probably missing something..
Just to be clear, the cookie is already set before the redirect, I'm not setting the cookie in the same response as the redirect.
According to this blog post: http://blog.dubbelboer.com/2012/11/25/302-cookie.html all major browsers, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0. 2), Opera (12.11) both on Windows and Mac, set cookies on redirects. This is true for both 301 and 302 redirects.
What is an HTTP 302? The 302 status code is a redirection message that occurs when a resource or page you're attempting to load has been temporarily moved to a different location. It's usually caused by the web server and doesn't impact the user experience, as the redirect happens automatically.
A 302 redirect does not pass the “juice,” or keep your domain authority to its new location. It simply redirects the user to the new location for you so they don't view a broken link, a 404 not found page, or an error page.
To redirect a site permanently, one should use a 301 redirect. This type of redirect is best for SEO purposes and also informs the search engines that the site has moved permanently. If you change your domain name and want to point to a different URL, a 301 redirect is your best choice.
It could be a bug in Chrome. See Chromium bug #696204. In my case the workaround was changing SameSite=Strict
to Lax
.
302 doesn't delete any cookie, so I think you are changing the host/port or the server expires the cookie. Look at this 3 requests (before 302, 302, after 302) and search something related to Set-Cookie header with a expires value.
It could be you have a problem with the cookie path, if you set the cookie path to a something different to '/', it will be not accessible to all paths.
Answering my own question. Turns out that one has to use a 303 (see other) response when redirecting from a post request.
From RFC 2616
10.3.4 303 See Other
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With