i know that cache control headers can be set on the pages coming out from the web-servers (that is responses). Does anyone know how cache control header should be set on the requests? Should it be done via client-side scripting? If yes, how?
I set cache control through PHP server side. At the top of your page, use the following code:
Using a date from the past ensures that the newest version of the page will always be downloaded.
I admit there might be cases when you want to alter the request headers, and it is easy enough to do for AJAX requests. I don't know any way of doing it for the "normal" click-on-link-request from the browser. Cf http://stackoverflow.com/questions/374885/can-i-change-the-headers-of-the-http-request-send-by-the-browser
But why would you alter the request headers? Are there anything like a cached request? The whole idea of constructing a request and send it to the server seems to be dynamic to me. What is it you want to achieve?
Cache-control requests are managed by the browser, there is no real reason to try and modify them. Firstly, for any URL visited, and all external requests from that page (images, scripts, styles) there is no way to control the requests.
For AJAX requests made after the page has loaded, it is possible to send specific headers (as detailed here), but it's complex and probably pointless. You don't say what your use-case is but you should probably just make your server send appropriate headers for the files in the first place.
All right, this is an old question, but here goes:
Cache control headers mainly have meaning for responses, i.e. what the server sends to the client. Setting cache control headers on the request is usually incorrect and meaningless.
The origin server sets the cache control headers, based on what is needed for the specific content. The person or organization managing the origin server configures this.
It is possible for the client software to disobey the cache control headers in violation of the RFCs, and store content which is explicitly marked
It is also possible for intermediary http caches (proxies) to disobey the caching headers on responses. And similarly, the individual or organization controlling the intermediary cache should fix this (and end users shouldn't permit intermediary caches which they don't trust).
In some circumstances, clients can specify certain criteria for which responses the client is willing to accept. See RFC 2616 section 13.1.6 Client-controlled Behavior. This is rarely used, and I wouldn't be surprised if a few intermediary caches out in the real world (less common corporate firewalls / anti-virus gateways / WAN accelerators) have bugs in the handling of this.
Lastly: I always recommend Mark Nottingham's Caching Tutorial for Web Authors and Webmasters as a really good, practical introduction to HTTP caching mechanisms.