looks like a possible RFC 2616 MUST violation see attached trace for details and ways to reproduce test case IDs in the trace link to human-oriented test case description and RFC quotes, if available
Created attachment 4349 [details] test case trace
Created attachment 7115 [details] Added the check for age > 24 hours, to print heuristic expiration warning.
Created attachment 7116 [details] Comments related to the patch.
Created attachment 7127 [details] same proposed changes, now in unified diff format
The proposed changes show no effect on the test case outcome for 2.0.46. The corresponding test case trace will be attached. Note that Apache seems to think that the age of the entity is zero rather than correct 24 hours. Apache cache might be ignoring the original Age response header in its calculations of entity age.
Created attachment 7130 [details] test case trace, against patched 2.0.46
Created attachment 7152 [details] Fix for adding warning 113
Attached the patch for printing the 113 warning (Attachment ID 7152). With this fix, if the origin server response has the Age value greater than 24 hours, 113 warning will be added to the response header, and the Age will have the value computed by mod_cache. About the problem, Age of the entity becoming zero, In the test case ID 4349 the cached response header is having TWO age directives, Age: 86403 and Age: 0. Is this the correct behavior?
According to RFC 13.2.3 this is incorrect. There should be at most a *single* Age header present. 13.2.3 ... When a response is generated from a cache entry, the cache MUST include a single Age header field in the response with a value equal to the cache entry's current_age.
You are correct. The RFC requirements you quoted, however, might lead someone to believe that the cache must _add_ an Age header, in addition to the one(s) that are already present. The format of the Age header prohibits that: Age = "Age" ":" age-value age-value = delta-seconds To allow for multiple age values, the header would have to be defined using a #list expression. Note that the latest test case (trace #7130) does not show Apache generating multiple Age headers so perhaps that bug got fixed.
Created attachment 7172 [details] unified diff version of attachment 7152 [details]
Created attachment 7173 [details] immediate hit case trace, 2.0.46 patched with attachment 7172 [details] (success)
Created attachment 7174 [details] delayed hit case trace, 2.0.46 patched with attachment 7172 [details] (violation)
The patch in attachment 7172 [details] brings partial success: Apache now passes a simple case when cached object is revisited immediately (attachment 7173 [details]). Apache still violates the case when the object ages in the cache; that is, when the object was less than 24 hours old when it was cached, but became more than 24 hours old in the cache (attachment 7174 [details]). Perhaps you are using the cached age as opposed to the computed/actual age at the time of request? Or the age calculation is broken. Please note that only attachment 7172 [details] patch was applied. When submitting patches, please generate unified diffs if at all possible.
Created attachment 7202 [details] Patch for printing 113 warning, when the origin server sends the aged object or the object gets aged in the cache.
With the patch in attachment 7202 [details], Apache passes all test cases in this test clause.
Created attachment 7434 [details] Adjusted version of attachement 7202.
I have attached a slightly altered version of attachement 7202. In the existing util_script code, any headers that do not specifically have cases in the switch should get added to the err_headers_out table by default. Headers that need to be passed on, regardless of request processing outcome, are supposed to be added to err_headers_out. Attachement 7202 essentially moved the Expires and Age headers from the err_headers_out over to the headers_out table. This is not correct. The correct action is to look in both places for the header and update it in the location that it was found. You will find that the ap_cache_check_freshness function in cache_util.c now checks for the Age header in both locations. My attached version of the patch (7434) checks both locations for the Expires header. The code should also add the warning to the existing Warning header (wherever it finds it). The 7202 patch also checked if ((age + age_c) > 86400)). This is incorrect because "age" is the corrected age, which is based on "age_c". Adding the two basically doubles the age. It should simply be (age > 86400). The final difference in the two versions of the patch is that RFC 2616 13.2.4 indicates that the 113 warning should be added "if such warning has not already been added." My altered patch checks if 113 is there before adding it. Could you folks at Measurement-Factory please verify that the attached patch (7434) works for you. If so, this will be the version I commit. Thanks for your work Sushma Rai and Co-Advisor.
Created attachment 7435 [details] delayed hit case trace, 2.0.46 patched with attachment 7434 [details] (violation)
With the patch in attachment 7434 [details], Apache violates both test cases in this test clause. I've attached the "6 second delay" case trace. Note that Apache is returning two Age headers now. The patch was applied to virgin 2.0.46. Are we doing something wrong when testing this patch?
Sorry, I do all my testing using 2.1-dev. That might explain some of the difference. Other differences might relate to the cache method used. I'm betting you are using mod_disk_cache? I usually use mod_mem_cache. I'm working on tracking down the differences between 2.0 and 2.1-dev and between mod_disk_cache and mod_mem_cache. They should both work the same, but I know that mod_disk_cache has more problems than mod_mem_cache.
Yes, we use the disk cache: ./configure --enable-proxy --enable-cache --enable-disk-cache We had been testing using 2.1-dev as well, but were forced to downgrade to 2.0 because most of the patches developers want us to test were against 2.0. If possible, we would prefer to wait for a version of your patch that works with 2.0. We can test 2.0 with memory cache if that helps.
I'm going through the bug db to make sure patches are findable. Please see http://httpd.apache.org/dev/patches.html
This looks like it has been resolved in the current releases of httpd mod_cache. Thanks1