[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3661:
----------------------------
Fix Version/s: 5.3.1
> cache broken during 3xx redirect follow response
> ------------------------------------------------
>
> Key: TS-3661
> URL: https://issues.apache.org/jira/browse/TS-3661
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 5.2.1
> Reporter: Sudheer Vinukonda
> Assignee: Sudheer Vinukonda
> Fix For: 5.3.1, 6.0.0
>
>
> During a 3xx redirect follow, the current TS implementation is that, it
> creates a new cache key for the redirect follow request and stores the
> response against the new cache key.
> There's some logic in *HttpCacheSM::open_write* that's basically to check
> that a txn is not stuck in a open_write loop.
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpCacheSM.cc#L289
> The logic basically is to check the current *open_write_tries* for a given
> *cache_sm* object against *proxy.config.http.cache.max_open_write_retries*
> and against *redirection_tries* for that txn. The assumption here is that, we
> allow atleast one *open_write_try* per redirect follow attempt.
> {code}
> if (open_write_tries > master_sm->redirection_tries &&
> open_write_tries >
> master_sm->t_state.http_config_param->max_cache_open_write_retries) {
> master_sm->handleEvent(CACHE_EVENT_OPEN_WRITE_FAILED, (void
> *)-ECACHE_DOC_BUSY);
> return ACTION_RESULT_DONE;
> }
> {code}
> However, the *open_write_tries counter* is incremented before checking the
> condition, while *redirection_tries* is only incremented after receiving the
> server response which is too late. This results in basically open_write_tries
> being incremented ahead and would always fail the check (except, for a
> non-default value (> 1) for *proxy.config.http.cache.max_open_write_retries*)
> Update: While the above is *a* possible issue, the real reason for this
> regression is not directly related to the above problem. The above problem
> actually ends up helping the cause (so to speak), since it basically fails
> all open_writes with the new cache key (location based) during redirect
> follow.
> The issue seems to have been resulted due to the commits in TS-3140, which
> close the original cache_sm before doing a redirect follow. Without this fix,
> the original cache_sm (opened against the original client URL as the key) is
> still open and is used to write the final (2xx) response from the origin.
> However, closing the cache_sm before redirect follow with TS-3140 makes it so
> that, the object never gets cached.
> Fixing this should be very simple. Either reset the *open_write_tries*
> counter in *cache_sm.close_write()* which is performed during the redirect
> follow (before open_write with new cache_key), or adjust the logic a bit
> (e.g. swap around the point at which the counters are incremented etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
