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
Cache Manager should not store at all response with header "no-cache" and sto...
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: HTTP
2.7
All All
: P2 enhancement (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-07-08 14:19 UTC by Philippe Mouawad
Modified: 2012-07-14 21:59 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Mouawad 2012-07-08 14:19:38 UTC
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
Comment 1 Philippe Mouawad 2012-07-08 14:24:52 UTC
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
Comment 2 Philippe Mouawad 2012-07-08 14:57:26 UTC
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
Comment 3 Sebb 2012-07-10 19:48:01 UTC
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.
Comment 4 Philippe Mouawad 2012-07-10 21:01:13 UTC
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
Comment 5 Sebb 2012-07-10 23:02:15 UTC
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
Comment 6 Philippe Mouawad 2012-07-14 14:26:55 UTC
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
Comment 7 Sebb 2012-07-14 15:02:45 UTC
(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".
Comment 8 Philippe Mouawad 2012-07-14 15:44:31 UTC
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.
Comment 9 Philippe Mouawad 2012-07-14 15:50:30 UTC
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
Comment 10 Philippe Mouawad 2012-07-14 15:58:39 UTC
Note if server does not send Last-Modified time , I don't see what the spec says about it.
Comment 11 Philippe Mouawad 2012-07-14 15:58:48 UTC
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
Comment 12 Philippe Mouawad 2012-07-14 19:04:32 UTC
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
Comment 13 Rainer Jung 2012-07-14 21:59:02 UTC
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