[
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)
