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!