We have a mobile web app saved to the home screen. The application is coded using a single page HTML file with jquery mobile.
In iOS5 and below the index.html file is not cached by the device so every time the application is launched the device requests for the HTML page. This is really important because we have another application that handles authentication sitting in front of our server and therefore we rely on the 302 http code which causes a redirect to authenticate. If this is successful another redirect occurs back to our index.html page.
In iOS6 though it appears the index.html file is cached even though we set a no cache control header! This is a problem because we don’t get to authenticate and therefore when the user starts using the application all requests fail (they are unauthenicated).
I can’t seem to find any detail of whether this was a feature implemented in iOS6. Anyone shed any light on this? I know they went a little crazy with caching (caching post responses)…
NOTE: understand the solution of the authentication is not ideal however we can’t change that at the moment. Just looking for references on what apple did to cause this bug!
Update:
Just discovered something interesting after using Charles Web Debugging Proxy that the server is responding with Cache-Control:private which means that proxies won’t cache however browsers will cache. This raises the question as to whether iOS 6 home screen mobile web apps now actually treat this cache-control correctly?!? Need to investigate further what hardware in our infrastructure is adding this cache-control.
I am having the same issue with an HTML5/JQM/Jersey based application. I set the cache-control header to no-cache, which now seems to work on most of the devices but still fails intermittently on some.