If you manage a Shibboleth SP and have been receiving complaints from Firefox 5 users, you may be running into an issue due to FF5’s more compliant caching of Location headers in 302 redirects. While this is a step in the right direction for front-end performance, even tiny HTTP handling changes can affect existing sites.

Particularly, if you’ve configured Apache with ExpiresDefault within a Shibboleth-protected realm, you may be asking for trouble. When Shibboleth redirects you to authenticate at the IdP, Firefox 5 will obey the Expires/Cache-Control headers sent with that initial redirect. After you log in, when the SP returns you to the resource, Firefox 5 won’t re-send the request at all. Instead it will re-forward you to the IdP, which will be confused and throw an error.

I found this confusing to debug because the HTTP logs showed the browser receiving a Location header, then immediately requesting a completely different URL.

The takehome is that redirects should never be sent with future cache headers unless you want those headers obeyed. Settings like ExpiresDefault should be avoided where Apache might issue one-time redirects, or, if Shibboleth protects a single directory (e.g. an application’s auth adapter) you should turn ExpiresActive Off in that directory. (Note this may not be a problem if a script issues the redirect because it may override Apache’s Expires header, and the author of the SP module is planning on dealing with this issue in a future patch.)

FWIW, IE9 and Opera also reportedly share FF5’s behavior (see the “302 future vary” column), but even though I occasionally use Opera, I never ran into this bug.