[ https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Sorber updated TS-3661: ---------------------------- Backport to Version: (was: 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)