[TS-4829] Via: header string should not be cached

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: sometime
• Assignee: Unassigned
• Reporter: Miles Libbey
• Created: 08/Sep/16 04:24
• Updated: 13/Oct/16 03:46
• Resolved: 13/Oct/16 03:46

Description

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