What you may not know about HTTP redirects

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 :)

3 Comments

  1. Thanks for this brilliant article. I am delighted after reading this. Thank you!

  2. Jaya Gupta

    Nice article. Thank you!

  3. Alex

    However, directly below that statement in spec, it also states: “Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.”

    The Post-Redirect-Get pattern is ubiquitous on the web. Specifically, I am trying to use rest assured to test my application, and I find I have to process all the redirects manually, which is annoying.

Leave a Reply