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
