I've deployed a transparent caching solution with several CE560 and NM-CE on r3745. The CEs are running ACNS 5.2.3 and I have three sites using ACNS 5.2.5 for testing purposes.
Everything is working fine, but now I face the following issue.
On several web servers when the content is modified, this modification is not reflected on the client(browser) side.
I've capture traffic on the CE interface and noticed that the CE is doing an HTTP IMS request to which the server answers with a 304 HTTP code (not modified).
This explains the CE behavior and the final result on the client (browser) side.
The problem is that the content was really modified and the client is accessing to an older version.
If I bypass the CE or clear the CE cache this "problem" is solved.
Why is the server answering with 304 if the content was really modified?
Can I do something on the CE side to avoid IMS requests (in spite of this doesn't make any sense because the CE is acting accordingly to what is expected when facing a 304 response code)
Thanks for your attention.
If a cached object's HTTP header does not specify an expiration time, the age-multiplier and max-ttl options provide a means for the Content Engine to age cached objects. The Content Engine's algorithm to calculate an object's cache expiration date is as follows:
Expiration date = (Today's date - Object's last modified date) * Freshness factor
The freshness factor is computed from the text and binary percentage parameters of the age-multiplier command. Valid age-multiplier values are 0 to 100 percent of the object's age.Default values are 30 percent for text and 60 percent for binary objects. After the expiration date,the object is considered stale and subsequent requests result in a fresh retrieval by the Content Engine. When the Content Engine authenticates a user through a server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is kept, subsequent attempts to access restricted Internet content by that user do not require LDAP server lookups. The max-entries option sets the maximum number of authentication ache entries retained. The timeout option specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires a server lookup for reauthentication.The max-ttl option sets the upper limit on estimated expiration dates. An explicit expiration date in the HTTP header (set by the web server) takes precedence over the max-ttl value.In order to solve the problem try using the "rule refresh" command.This is because The freshness algorithm is interesting in that CE takes into account the Modified Since Date - if the age hasn't been modified for awhile - the algorithm will consider it fresh longer. About the best way to guarantee the freshness of a certain site is to use the "rule refresh" command or "'http reval-each-request "
Thanks for your reply.
Today I will do additional tests trying to understand better what's going on.
My problem is that the CE is issuing IMS requests (has expected), to validate its content, to which the server is answering with a HTTP 304 response code, stating that the content hasn't change since the last modified date. But the truth is that the content has been modified and the server shouldn't respond with an HTTP 304 error code.
Thanks again for your interest in this issue.
When a client browser issues a conditional get (IMS request) we should expect that any CE existing between this client an a Web Server revalidates its content with the Web Server.
Is there any situation where the CE will not revalidate its content when facing an IMS request (for example ctrl+refresh on IE browser) from the client side and delivers the client its cached content?
Thanks in advance,