Dan, Could you check if the check-in for this fix is breaking some end to end tests:
https://builds.apache.org/view/S-Z/view/Shinding/job/Shindig/2777/#showFailuresLink - Henry On Wed, Apr 25, 2012 at 8:36 AM, Xiao Feng Yu (JIRA) <[email protected]> wrote: > Xiao Feng Yu created SHINDIG-1759: > ------------------------------------- > > Summary: Shindig returns the response that should not be cached > Key: SHINDIG-1759 > URL: https://issues.apache.org/jira/browse/SHINDIG-1759 > Project: Shindig > Issue Type: Bug > Components: Java > Affects Versions: 3.0.0 > Reporter: Xiao Feng Yu > > > We recently find a issue with Shindig cache. The problem can be happens with > the following conditions > 1) Client perform a makeRequest call with refresh equals 0. > 2) The clock of web resource server is about 1.5 minutes faster than the > clock of Shindig server > 3) The web resource server returns the resource with Cache-Control header set > to no-cache. > When user A perform a makeRequest call to the web resource, it will get the > response correctly, and then the second user B performs the same makeRequest > call, Shindig returns the cached response. But in fact, it should not, > because refresh equals 0 is specified and Cache-Control: no-cache is present > in the response. > The reason is beause refresh equals 0 will override the > cache-control:no-cache header in response with Cache-Control:public,max-age=0 > header. And the next time, the cached response retrieved, the TTL of the > cached response will be calculated by Date header. And because of the clock > skew (Shindig only fix the time drift larger than 3 minutes), it leaves a > time window in which the cached response will be returned, while it should > not be. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > >
