On Thu, Jun 30, 2011 at 5:58 PM, Michael Stevens <michael.stevens@xxxxxxxxxxxxxxxx> wrote: >> What is generating the different responses? > > We use the Spring Security authentication framework on Tomcat using an APR connector behind Apache. > > Protected resources are handled like this for an unauthenticated user: > > GET /some/protected/resource.html > Response: 302 /login.html > GET /login.html > Response: 200 > POST /login.html > Response: 302 /some/protected/resource.html > > This is a pretty standard scenario in authentication and single sign-on frameworks. In the example, /some/protected/resource.html cannot be cached by the client since the same expires/cache-control headers will be included with the 302 response, and Firefox 5 will cache the 302, causing the second request to the resource to again redirect to /login.html. > > -Michael > 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. Ergo, don't send those headers, or send ones that make it explicitly clear that you don't want the page cached, eg Cache-Control: no-cache, or Expires in the past. Cheers Tom --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|