[
https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571649#comment-14571649
]
Sudheer Vinukonda commented on TS-3652:
---------------------------------------
After some more investigation, it turns out that this is due to a regression in
5.3.x (refer TS-3661).
Basically, TS stores the final (2xx) response after the redirect follow
attempts against the original client url (or a modified cache key via API). All
the intermediate 3xx responses should never be stored in the cache (even though
there's a lot of code that tries to build a new cache key with the Location
header and tries to store the 3xx responses, all those read/writes fails,
since, the cache_sm for the original key (client request or modified API key)
still is open). Confirmed that this is indeed the case by removing the part of
the commit from TS-3140 that closes cache_sm during redirect follow.
Closing this jira as invalid, since the request in the jira is how TS is
expected to behave anyway (will fix the regression introduced by TS-3140 using
TS-3661)
> 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)
