The fix turns out to be a little simpler; I adjusted how CachedPortletData values are stored in the cache when validation method is being used.
I have a question now to follow that goes along with the ongoing Git discussions: Should I just issue a Pull request right away? Or is there a way for the reporter of the issue to snag my changes, try them out locally to confirm? Here's my change: https://github.com/nblair/uPortal/commit/c743c295ea6fe868bace8c0069333d2d6b308043 On Thu, Oct 20, 2011 at 4:58 PM, Jen Bourey <[email protected]>wrote: > Hi all, > > I think I've encountered some misbehavior in uPortal 4's validation-based > resource URL caching. To summarize, it looks like portlets send back blank > responses when a portlet thinks the ETag matches, but the content itself has > expired out of the portal's cache. > > I think I can currently demonstrate this behavior using the Jasig Test > Portlet's Cache Control (CacheControl Validation Method) Test. If you click > the "Get JSON content" button, the first request will appropriately send > back a 200 OK response with content, and a subsequent click will result in a > blank 304 Not Modified response. However, if I wait longer than two > minutes, then click the button, I appear to get a 200 OK response with no > content. > > First of all, I think we might want to update the functional test portlet's > CacheTestController.writeJsonContentWithValidationCaching method to validate > the ETag included in the request. It would be useful for the test case to > be able to distinguish between requests that include a still-valid ETag and > a request that has an Etag that doens't match our conception of "current". > > Beyond our test cases though, it seems that the portal needs to be able to > respond to a request that has a still-valid ETag, but for which content has > expired out of the portal's cache. In the case of resource URLs, it seems > like it should be OK that the content is missing from the cache, since we > don't actually want to send the content itself back. I think we just want > to send back a 302 header and move on. > > Has anyone else encountered this behavior in the test case? Does my > reading of the intended behavior for resource URLs sound correct? > > - Jen > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
