From dev mailing list discussion on 07 july 2012: Sebb: "I don't have the source to hand at present, but we should not cache at all if Cache-Control=no-cache; the max-age is then not relevant." Philippe M. "Looking at existing code, I noticed that with no-cache we store an entry in Cache for which CacheManager#inCache will return false . I don't understand why we just skip the entry, currently we use one entry in map for nothing." Conclusion of discussion: - Staled entries for "no-cache" will not be stored anymore - Cache-control will only be checked for no-cache, for other values, responses will be stored in cache using max-age value
Date: Sun Jul 8 14:23:54 2012 New Revision: 1358746 URL: http://svn.apache.org/viewvc?rev=1358746&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestCacheManager.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
Date: Sun Jul 8 14:56:27 2012 New Revision: 1358753 URL: http://svn.apache.org/viewvc?rev=1358753&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java
Following further discussion on the developer list it was pointed out that "no-cache" does not mean the response should not be cached. Rather, it means that the cache entry must not be used without re-validation.
Date: Tue Jul 10 21:00:33 2012 New Revision: 1359898 URL: http://svn.apache.org/viewvc?rev=1359898&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value (edit) Fix broken test Bugzilla Id: 53522 Modified: jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestCacheManager.java
URL: http://svn.apache.org/viewvc?rev=1359858&view=rev Log: no-cache responses should be stored, but must be revalidated, so don't store an expiry date for them Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java
Date: Sat Jul 14 14:25:11 2012 New Revision: 1361551 URL: http://svn.apache.org/viewvc?rev=1361551&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Changed to store entry forever if no max-age and no expires header which is what specification says in my understanding: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java jmeter/trunk/xdocs/usermanual/component_reference.xml Date: Sat Jul 14 14:26:03 2012 New Revision: 1361552 URL: http://svn.apache.org/viewvc?rev=1361552&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Added test case Added sleep to ensure entries become invalid after their expiration date has passed Bugzilla Id: 53522 Modified: jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestCacheManager.java
(In reply to comment #6) > Changed to store entry forever if no max-age and no expires header which is > what specification says in my understanding: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html I'm not sure that's a valid interpretation of the spec. I cannot find any reference to a missing expiry date as never expiring. But I could be wrong. Note that section 14.21 says: "To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent." So if it is valid to assume a missing expiry date means "never expires", then using two weeks is non-standard; we should use 1 year instead. But first we need to establish that a missing expires/max-age really means "never expires".
http://www.ietf.org/rfc/rfc2616.txt 13.2.4 From : https://developer.mozilla.org/en/HTTP_Caching_FAQ You are right I put 2 weeks for infinite (as I thought no test would last 2 weeks). But now I am implementing the what the RFC says.
Date: Sat Jul 14 15:49:16 2012 New Revision: 1361555 URL: http://svn.apache.org/viewvc?rev=1361555&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Implemented RFC 2616 section 13.2.4. Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/util/HTTPConstantsInterface.java jmeter/trunk/xdocs/usermanual/component_reference.xml
Note if server does not send Last-Modified time , I don't see what the spec says about it.
Date: Sat Jul 14 15:55:11 2012 New Revision: 1361556 URL: http://svn.apache.org/viewvc?rev=1361556&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Fixed test case Bugzilla Id: 53522 Modified: jmeter/trunk/test/src/org/apache/jmeter/protocol/http/control/TestCacheManager.java
Date: Sat Jul 14 19:03:54 2012 New Revision: 1361574 URL: http://svn.apache.org/viewvc?rev=1361574&view=rev Log: Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value IF Last-Modified or Date are missing or invalid, set expiration date to one year in future Bugzilla Id: 53522 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java
For the sake of completeness some relevant parts from the specs: RFC2616: 13.2.2 Heuristic Expiration Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible. ... 13.2.4 Expiration Calculations ... If none of Expires, Cache-Control: max-age, or Cache-Control: s- maxage (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. The cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added. Also, if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. The current Draft document for HTTPbis (draft-ietf-httpbis-p6-cache-19) formulates it a bit different and mentions further restrictions: 2.3.1.1. Calculating Heuristic Freshness If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness to be used (including the following in Section 7 of [Part2]: 200, 203, 206, 300, 301 and 410), a cache MAY calculate a heuristic expiration time. A cache MUST NOT use heuristics to determine freshness for responses with status codes that do not explicitly allow it. When a heuristic is used to calculate freshness lifetime, a cache SHOULD attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already present. Also, if the response has a Last-Modified header field (Section 2.2 of [Part4]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do not calculate heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control: no-cache) if they wish to preclude caching. Regards, Rainer
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2858