[
https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568961#comment-14568961
]
Alan M. Carroll commented on TS-3652:
-------------------------------------
Originally I thought it might be best to declare that if the cache key is set
via the API, that's it, it can't change. But I think there may be situations
where even if a plugin doesn't set the cache key it would be useful to be able
to inhibit changing the cache key during a redirect.
But rather than a separate override var to control this, we may want to extend
the values that can be passed to TSRedirectEnable() to include "disable",
"enable", "enable with locked cache key".
> 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)
