Sometimes, we inherit code and just plain have to deal with it. A legacy app coded by previous developers. A Web-based application or library integrated into a site.
What happens if you get HTTP cache control headers in a Web response that you did not expect from an application that then caches a file longer than you want to on browser and proxy caches?
This could be especially problematic if the file that is getting cached is a dynamic ASP, ASPX, CFM, PHP or JSP file, and you may really need to kill those headers caching these files on the browser. This could lead you to have to search through the code to find where the header is injected, which may be time consuming or hard if not impossible to find.
On IIS, you can solve this challenge with CacheRight and trap/modify/remove unwanted cache control headers. Here are a few steps to try:
1. In the CacheRight rules file, set the default rule to:
ExpiresDefault : immediately public
Or, set up a rule for how you want the dynamic files to be cache controlled, depending on the cache policy you want to enforce…
2. Then, using the block by path rule to exclude your dynamic files (.JSP files, in this example, in a particular directory; wildcards work to control for extension, if you needed this much control versus blocking a whole directory):
BlockByPath /JSP Folder/* :
3. Additionally, make sure the “Override existing cache control headers” box in the CacheRight Settings Manager is checked.
4. This will force CacheRight to remove all of the cache control headers in your dynamic files, thus allowing for the user’s browser or a proxy cache to request the standard 304 modification check.
The result? No uncontrolled caching headers that break dynamic pages from the code base you inherited or integrated.
Best regards,
Port80