You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Mat Mannion (JIRA)" <ji...@apache.org> on 2010/06/01 15:35:40 UTC
[jira] Created: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
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: 1.0.1, 2.0.0-RC1
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.
[jira] Assigned: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Hjelmstad reassigned SHINDIG-1346:
---------------------------------------
Assignee: Pradnya Karbhari
> 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
> 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.
[jira] Resolved: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875037#action_12875037 ]
John Hjelmstad commented on SHINDIG-1346:
-----------------------------------------
Hmm, disregard. On further thought, this isn't related to Etags support in the proxy at all. Apologies.
> 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
> 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.
[jira] Updated: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "Pradnya Karbhari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pradnya Karbhari updated SHINDIG-1346:
--------------------------------------
Attachment: fix-1346-bug.patch
Code review at:
http://codereview.appspot.com/1605041/show
> 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
> 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.
[jira] Updated: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875036#action_12875036 ]
John Hjelmstad commented on SHINDIG-1346:
-----------------------------------------
Hi Mat:
This isn't directly a Shindig issue at the moment, since as you note it doesn't include If-Modified-Since or ETags support, each of which yielding 304s.
However, we may implement ETags support soon:
https://issues.apache.org/jira/browse/SHINDIG-1350
...so I'll try to move this bug as a child of that.
> 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
> 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.
[jira] Updated: (SHINDIG-1346) DefaultRequestPipeline will cache
(and serve) 304 responses
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Hjelmstad updated SHINDIG-1346:
------------------------------------
Parent: (was: SHINDIG-1350)
Issue Type: Bug (was: Sub-task)
> 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
> 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.