safari redirect caching bug

Question

Level 1

5 points

safari redirect caching bug

At some point recently, Safari's caching with respect to 302 redirects changed.

I have the following setup:

URL A is handled dynamically, and redirects the user to one of several possibilities.
One of the possibilities is to redirect (302) to a static HTML page.

If I start up a fresh Safari process then the first time I go to URL A, then it's handled correctly. Any subsequent attempts to go to URL A result in the browser immediately showing the cached static content, and never hitting A.

This still works as expected (ie how it's been working for the last few years) on all other browsers, but it looks like this behaviour changed with the most recent Safari releases. It's true for Safari 7.0 on Mavericks and 6.1 (8537.71) on Mountain Lion.

Obviously I can code round this, but the behaviour seems surprising.

Neil

MacBook Pro & Powerbook

Posted on Nov 6, 2013 7:23 AM

Reply

Answer 1

Nov 14, 2013 12:25 PM in response to neilbowers

I'm seeing this behavior on iOS 7 Safari, probably older versions as well though I've not confirmed yet.

We have a web filter. When a web page is blocked, a 302 redirect is issued redirecting to a block page which tells the user that the site is blocked, why it is blocked, and lets them log in to bypass the block. Upon logging in, the user should not longer be redirected to a block page. Revisiting the blocked site, now unblocked, results in the 302 redirect again. The only solution is to clear safari cache and try again, but this is too complicated for the majority of users.

Reply

Answer 2

Mar 20, 2014 6:05 PM in response to killebrewj

I actually tried to clear my cache today and a redirect that was removed was still "cached" by Safari. I ran `curl -v` and that returned the expected result.

Details: Safari v7.0.2; OS X 10.9.2

Reply

Answer 3

wcbrown

Level 1

10 points

Jul 21, 2015 4:32 PM in response to neilbowers

I figured it out. Set the "cache-control" header to "no-store" and Safari will observe the request. I've been struggling with this bug since February and I finally had a breakthrough once I could isolate it to Safari caching the 302 redirect.

That led me to this open WebKit bug and the final comment:

CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.

It fixed everything for me on desktop and mobile Safari. Hope it helps!

Bill Brown

Reply