Firefox 5 Shibboleth Issues

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.

2 thoughts on “Firefox 5 Shibboleth Issues

  1. George says:

    Thank you for posting this! This was driving me crazy and I would never have solved it without the info you posted.

  2. says:

    Steve, thanks for the great analysis and pointers. I help to manage a couple of affected sites, and this post led me to the solution.

    FWIW, Drupal ships with several mod_expires options set by default, and I was concerned about setting ExpiresActive Off for all content, and so instead fixed it using ExpiresByType text/html A1, within the mod_expires section of $drupal_root/.htaccess, while leaving ExpiresActive On enabled for other content types.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.