Re: [uportal-dev] Resource URL ETag Validation Caching

[Eric Dalquist]

So I'm guessing there is a bug in the portal's portlet cache management logic. In the case you're describing, where a portlet returns content and sets an expiration time and an etag the logic on following requests should follow:

1. check if there is cached content for the request that matches the etag

3. if the portlet returns 'still valid' the portal should return a 304





Thanks,
-Eric

On 10/20/2011 04:58 PM, Jen Bourey wrote:

2. on cache miss call the portlet's render/resource method and provide the etag I'm thinking the bug is in step 3 and the portal isn't handling the 'content still valid' return from the portlet correctly. Your thinking is right and is what is currently intended, could you create a jira issue with the summary here and assign it to Nick?

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

smime.p7s
Description: S/MIME Cryptographic Signature