Saturday, September 22, 2012

Developers claim Safari in iOS 6 breaks Web apps with aggressive caching

Developers claim Safari in iOS 6 breaks Web apps with aggressive caching:
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.
Read 4 remaining paragraphs | Comments


DIGITAL JUICE

No comments:

Post a Comment

Thank's!