[
https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Lindner resolved SHINDIG-1346.
-----------------------------------
Fix Version/s: 2.0.0-RC1
Resolution: Fixed
patch committed by John
> DefaultRequestPipeline will cache (and serve) 304 responses
> -----------------------------------------------------------
>
> Key: SHINDIG-1346
> URL: https://issues.apache.org/jira/browse/SHINDIG-1346
> Project: Shindig
> Issue Type: Bug
> Components: Java
> Affects Versions: 2.0.0-RC1, 1.0.1
> Reporter: Mat Mannion
> Assignee: Pradnya Karbhari
> Priority: Minor
> Fix For: 2.0.0-RC1
>
> Attachments: fix-1346-bug.patch
>
>
> Currently in our product we are making use of DefaultRequestPipeline in our
> own code (to reuse the OAuth stores and make authenticated requests). Some of
> this code adds an If-Modified-Since header to a HttpRequest, and passes it
> into the RequestPipeline. If the response is not already in the cache and the
> server returns a 304, this is being added to the HttpCache, causing
> subsequent requests to return a 304 as well.
> This is catching us out where we have custom code that periodically fetches
> RSS feeds, because the 304 is being cached and then returned for
> contentType=FEED makeRequests by gadgets, which can't be parsed by Rome and
> is propagating empty objects to the gadgets themselves. At the moment, I'm
> not sure if this is something that necessarily needs to be fixed in Shindig
> (we are getting around this by injecting a wrapping implementation of
> HttpCache that doesn't cache 3xx responses) but if any Shindig code ever
> starts using this header, or this header is exposed to gadgets, it could
> cause issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
