Web developers are reporting that the Safari Web browser in iOS 6 is breaking the applications they're writing thanks to aggressive caching. Discussion of the issue on Stack Overflow explains that Safari is remembering the server responses to certain requests and then reusing those responses, even though a new response should be requested every time.
Web requests can take many forms, but there are two main kinds: GET and POST. As a general rule, POST should be used when you expect there to be a side-effect of some kind; GET should be used when there is no side-effect. So, for example, a search for a book on Amazon should use a GET; since searching doesn't change any state (it doesn't place any orders, or change your billing information, or anything like that), GET is appropriate. The final "Buy" button in the checkout, however, should use POST, because it has a big side-effect: your credit card gets billed, a book is shipped out, and so on.
Because of this fundamental difference, the two have different default rules about caching. GET requests can generally be cached; the result of a GET is broadly expected to be the same each time, and since there's no side-effect from a GET it doesn't actually matter if a browser sends the request to a server, or just uses a cached response. POST, on the other hand, generally can't be cached. If you want to know what the result of a POST is, you have to ask the server again, because the response may very well be different—to use the Amazon example again, your credit card might refuse the transaction the second time around, or the book may now be out of stock.
POST responses are not completely uncachable, but according to the HTTP specification the responses must explicitly indicate that they can be cached. The responses to GET requests don't require this explicit indication; instead, there are generic rules that are applied.
Evidence suggests that Safari on iOS 6 is ignoring these rules. Developers are using POST for operations with side-effects, but Safari is caching the results and not giving applications the correct response. The result is that the apps are prone to breaking.
A number of solutions have been proposed at Stack Overflow. When developers have control of both the server and the client, they can configure the server to explicitly indicate that responses shouldn't be cached. This shouldn't be necessary, and isn't required for any other browser, but Safari will pay attention if caching is suppressed. When developers only control the client, they can add a timestamp or similar to each POST they make, to ensure that no two posts are identical. This assumes that the server doesn't mind receiving a timestamp it neither wants nor asked for.
Whether this is a bug or a deliberate attempt by Apple to improve perceived performance of its browser is as yet unclear. We've asked Apple for comment, but as yet have heard nothing back.
reader comments
53