[
https://issues.apache.org/jira/browse/SHINDIG-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262886#comment-13262886
]
[email protected] commented on SHINDIG-1759:
--------------------------------------------------------
bq. On 2012-04-26 14:56:26, BrianLillie wrote:
bq. > As noted in the JIRA, the issue with the no-cache being returned on the
first request, and the (incorrect) cached response on the second request occurs
due to the modification of the cached response in the
AbstractHttpCache.addResponse. This code slams the request's refresh interval
onto the cache-control headers, and puts that into the cache, while the
original request with no-cache is returned to the user. It seems like this
fix would address only one specific issue, that of an incoming request with
refresh interval = 0. If the refresh interval specified by the client is
sufficiently smaller than the time skew between the two servers, wouldn't the
same issue occur ?
Hmmm...
In my experience a max-age on a cache response indicates the maximum period of
time before you should toss out the whole cached object and ask again. Not
that you shouldn't ask until you've hit the max-age (which i thought what
expires was for).
So should we treat all responses as stale if they come back with max-age so
that we can ask with a last-modified query? I think this is what browsers do.
- Dan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4877/#review7263
-----------------------------------------------------------
On 2012-04-26 02:15:03, Xiao Feng Yu wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/4877/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-04-26 02:15:03)
bq.
bq.
bq. Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and
Brian Lillie.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Since max-age=0 means the response expires immediately when the response
is generated, and there is no need to compute TTL with possibly incorrect
server time.
bq. We can update the isStale method in HttpResponse to return true if max-age
equals 0 instead of relying on computed TTL.
bq.
bq.
bq. This addresses bug SHINDIG-1759.
bq. https://issues.apache.org/jira/browse/SHINDIG-1759
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/HttpResponse.java
1330087
bq.
bq. Diff: https://reviews.apache.org/r/4877/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq.
bq. Thanks,
bq.
bq. Xiao Feng
bq.
bq.
> 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
> Labels: patch
> Fix For: 3.0.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> 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
