The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
I use new Date().getTime(), which will avoid collisions unless you have multiple requests happening within the same millisecond.
ReplyDeleteThe following will prevent all future AJAX requests from being cached, regardless of which jQuery method you use ($.get, $.ajax, etc.)
ReplyDelete$(document).ready(function() {
$.ajaxSetup({ cache: false });
});
Personally I feel that the query string method is more reliable than trying to set headers on the server - there's no guarantee that a proxy or browser won't just cache it anyway (some browsers are worse than others - naming no names).
ReplyDeleteI usually use Math.random() but I don't see anything wrong with using the date (you shouldn't be doing AJAX requests fast enough to get the same value twice).
A small addition to the excellent answers given: If you're running with a non-ajax backup solution for users without javascript, you will have to get those server-side headers correct anyway. This is not impossible, although I understand those that give it up ;)
ReplyDeleteI'm sure there's another question on SO that will give you the full set of headers that are appropriate. I am not entirely conviced miceus reply covers all the bases 100%.
What about using a POST request instead of a GET...?
ReplyDelete(Which you should anyway...)
Maybe you should look at $.ajax() instead (if you are using jQuery, which it looks like).
ReplyDeleteTake a look at: http://docs.jquery.com/Ajax/jQuery.ajax#options and the option "cache".
Another approach would be to look at how you cache things on the server side.
Of course "cache-breaking" techniques will get the job done, but this would not happen in the first place if the server indicated to the client that the response should not be cached. In some cases it is beneficial to cache responses, some times not. Let the server decide the correct lifetime of the data. You may want to change it later. Much easier to do from the server than from many different places in your UI code.
ReplyDeleteOf course this doesn't help if you have no control over the server.
You can use the short notation $.now() instead of doing a (new Date().getTime()) each and everytime.
ReplyDelete