There are many causes for this problem. Complete the following steps to determine whether a difference between the Last-modified time in the 200OK responses is causing the ProxySG to not cache the object, making the traffic between the ProxySG and the internal web server larger than it should be.
- Start a packet capture on the ProxySG.
- Try to access the internal Web server and press Ctrl+F5 to refresh the Web page.
- Stop the packet capture on the ProxySG.
- Open the pcap and find the http request to that web server.
- Follow the TCP stream.
- Analyze each http get and 200OK response for this Webpage.
- Because you pressed Ctrl+F5, the get requests should contain 'Pragma:no-cache' like this:
GET /CMS5_G20306002Resource?info=30419619;res=13106113899671245766770 HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)
Pragma: no-cache -------->this is a force refresh requst, Ctrl+F5
- Check the Last-Modified value in 200OK response sent by Web server.
HTTP/1.1 200 OK
Date: Wed, 02 Nov 2011 05:57:12 GMT
Last-Modified: Tue, 20 Dec 2011 01:57:12 GMT ---------->OCS send the object again and set the last-modified time tag.
X-Powered-By: Servlet/2.4 JSP/2.0
Keep-Alive: timeout=5, max=9936
- If you can find a Last-Modified time in 200OK response that is not the same or similar to other 200OK responses, and this time is near your request send out time, then this problem is related to the Last-Modified time setting in Web Server.
If the object you requested is a real time object and should not be cached, then this time setting is OK.
If the object you requested is not a real time object and can be cached, then this time setting should be changed to match the time of the other objects you requested.
- To resolve the issue, change the Last-Modified time setting in OCS to match the Last-modified time setting on the ProxySG.