Yesterday we wrote some integration tests using the REST Assured framework to verify URL authorization for our web application configured with Spring Security. Spring Security is configured to redirect the user to a login page if he or she is not yet logged in. It does this by sending a HTTP response with status code 302 and the URL to the login page specified in the location header. This is all fine and our tests verified that we were indeed redirected to the login page since REST Assured was configured to automatically follow redirects. But to our surprise one test failed for a particular web resource, the problem was that we were not redirected to the login page even though the response did in fact include status code 302 and the correct location header. We started digging around for the reason and after a while we ended up reading about the 302 response in the HTTP specification. Here it says:
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
The failing test was indeed using a POST request which means that HTTP Client will not automatically follow the redirect. How ever status code 303 (See Other) actually allows a user agent to automatically follow redirects:
This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.
So a solution for this would be to use 303 instead of 302 if we wanted the same behavior for POST requests. In our current application this was not a big deal so we decided to leave it for now. It would be interesting to know how (if possible) to configure Spring Security to use 303 instead of 302 but I leave this as an exercise for you as a reader :)