Miles Libbey created TS-4829:
--------------------------------
Summary: Via: header string should not be cached
Key: TS-4829
URL: https://issues.apache.org/jira/browse/TS-4829
Project: Traffic Server
Issue Type: Bug
Reporter: Miles Libbey
We use a cache hierarchy. In theory the Via: string shows the path the request
took through proxies, and with proxy.config.http.insert_response_via_str set to
3, a lot of info is presented -- cache hit, etc. (The Via header is described
in
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45)
However, the string is cached, so it doesn't accurately reflect the path that
*this* request took. Instead, it shows the path of the original request.
For instance, imagine 2 servers, conveniently named child.example.com and
parent.example.com, which also represents their roles in the cache hierarchy.
The object is cacheable for a long time.
The first request for the object might look like:
Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t
cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1 [uScMsSf
pSeN:t cCMi pSs ])
(with the cM meaning cache miss). The second request, a cache hit that just
goes through child.example.com might show:
Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t
cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p
eN:t cCHi p s ])
eg, cache Hit for child, but cache Miss for parent -- even though the parent
wasn't involved in the request, and, if it were, it would be a Hit. The parent
portion was cached by child.example.com.
The expected behavior is that the 2nd request would yield:
Via: http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p eN:t cCHi
p s ])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
