Safari observed caching the IdP login page

[Ryan Larscheidt]

I recently moved where the static CSS and image content on our IdP's login page is hosted, but kept it in the old location "just in case".  Luckily it seems, because to my surprise I observed Safari clients continuing to load the CSS and images from the old locations, which implied that they had cached the HTML of the IdP's login page.

After some Googling I found more reports that Safari's caching behavior is a nightmare, but (in theory) adding "Vary: *" to the response headers will fix it.  I have yet to try this, but Apple's login page sets the header so there might be something to that.

I've only seen the IdP set "Cache-Control: no-store" on the profile endpoints, which doesn't appear to be enough.  With the anti-CSRF functionality IdPv4, I can imagine that these Safari clients would be hopelessly broken if they continued caching the login page with stale tokens.

I'm wondering if the IdP could "more aggressively" set cache busting headers (e.g. "Cache-Control: private, no-cache, no-store", "Expires: 0", "Vary: *")?  Does that seem like a reasonable solution?

Thanks,
Ryan