[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295705#comment-14295705 ]
William Bardwell commented on TS-2912: -------------------------------------- Our fix was just: {code} diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc index 99bd2c2..9a086ce 100644 --- a/proxy/http/HttpTransact.cc +++ b/proxy/http/HttpTransact.cc @@ -4295,7 +4314,7 @@ HttpTransact::handle_cache_operation_on_forward_server_res ponse(State* s) } else if (!cacheable) { s->cache_info.action = CACHE_DO_DELETE; } else if (s->method == HTTP_WKSIDX_HEAD) { - s->cache_info.action = CACHE_DO_DELETE; + s->cache_info.action = CACHE_DO_NO_ACTION; } else { ink_assert(s->cache_info.object_read != 0); s->cache_info.action = CACHE_DO_REPLACE; {code} > HEAD transaction on stale entry deletes cache entry > --------------------------------------------------- > > Key: TS-2912 > URL: https://issues.apache.org/jira/browse/TS-2912 > Project: Traffic Server > Issue Type: Bug > Components: HTTP > Reporter: William Bardwell > Assignee: weijin > Labels: review > Fix For: 5.1.0 > > Attachments: ts-2912.try1.diff > > > On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 > comes back > HttpTransact::handle_cache_operation_on_forward_server_response(State* s) > deletes the cache entry, it seems like it should just ignore it (or check > ETag/Last-Modified and maybe delete if those don't match, but not > unconditionally.) > I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code > looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)