cache issues

Client side (browser) caching must be controlled by the developer. If ignored, you will likely experience problems, especially with dynamic web sites and applications.

old static content pages will be shown to users
old versions of dynamic web pages will be shown to users
new stylesheets and scripts will not be loaded with the page, so layout and javascript bugs are present
pdf or other binary file downloads will fail
pdf or other binary inline displays will fail

unnecessary page loading for every request when content doesn't change
slow performance for the client going page to page
server load is increased under high traffic

The same page request can be cached by the client, or by the client's proxy server, even if you do your part to tell it not to. This is because some organizations have very aggressive caching policies to control bandwidth. One way to prevent this, is to always change the url. This can be accomplished by adding a timestamp onto the end of the url. You can do this through php or javascript.

OLD URL:
http://www.example.com/products/list/

NEW URL:
http://www.example.com/products/list/?ts=<?=time()?>

...the NEW URL might look something like this on output:
http://www.example.com/products/list/?ts=1258776186

It is also common to do this but encode the entire GET string, such as with base64 encoding. You can pass any variable as usual, just add the timestamp as shown above. The cryptic mess looks less inviting to a user to mess with than a series of variables and values. Just pass the encrypted string as a value of some generic variable name, such as 'do'. It might turn out like this:

http://www.example.com/products/list/?do=dHM9MTI1ODc3NjQwOQ==

PHP has a function named session_cache_limiter(). This allows you easily control caching. Some claim that it doesn't work, and that other settings or tags are necessary to accomplish your intended behavior.