[jira] [Closed] (TS-3661) Cache broken during 3xx redirect follow response

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom closed TS-3661.
-----------------------------

> 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)