[
https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569667#comment-14569667
]
Leif Hedstrom commented on TS-3652:
-----------------------------------
Ok, so this is all confusing as hell. So if I understand this issue, it stems
from the fact that the cache key when following redirects is (and expects to
be) the Location: header as sent on the first response from origin (the 3xx
response). And when you use the APIs to modify the cache key, that cache key
gets sticky, and we no longer use the Location header for the cache key?
If so, as ugly as this current implementation is, it now seems pretty
reasonable to me that fixing it such that we "reset" the cache key between the
two transactions is reasonable. Meaning, the follow redirection event shouldn't
use the cache key from the API, it should continue to use the
Location-header-as-cache-key logic (by default, unless a plugin otherwise
modifies it).
Expecting a complete rewrite of this entire feature to fix what is an apparent
bug seems very draconian. If the issue is really around the interpretation of
Location: header as a cache key when following redirects, I don't have a
problem simply resetting the cache key between the two transactions.
> During 3xx redirect follow, TS uses the redirect url as the cache key
> ignoring any cache key set via API
> --------------------------------------------------------------------------------------------------------
>
> Key: TS-3652
> URL: https://issues.apache.org/jira/browse/TS-3652
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Sudheer Vinukonda
>
> Currently, during 3xx redirect follow, TS uses the redirect url (as received
> in the *Location* header of the 3xx response) as the cache key for storing
> the subsequent response to the redirect follow request. This works fine in
> most cases, since, the original client request would have cached the 3xx
> response and the final response would still be derived using the redirect
> follow url. This also allows direct requests to the redirect follow location
> be served from the cache efficiently.
> However, this is not desirable in some cases, especially when there's a TS
> API (plugin) modifying the cache key and wanting to store the final response
> against the modified cache key directly.
> Proposing to add a config setting to allow storing API set cache key during
> redirect follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
