[
https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad updated SHINDIG-1346:
------------------------------------
Parent: SHINDIG-1350
Issue Type: Sub-task (was: Bug)
> DefaultRequestPipeline will cache (and serve) 304 responses
> -----------------------------------------------------------
>
> Key: SHINDIG-1346
> URL: https://issues.apache.org/jira/browse/SHINDIG-1346
> Project: Shindig
> Issue Type: Sub-task
> Components: Java
> Affects Versions: 2.0.0-RC1, 1.0.1
> Reporter: Mat Mannion
> Priority: Minor
>
> 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.
