Friday Aug 10, 2007

Caching with JSR 286

    The public review draft of JSR 286 was recently released and the related files can be downloaded from this link. One of the major changes introduced in the new Portlet specification is how the caching of markup and resources can be done by the Portlet Container. I just want to highlight the differences between the caching part of JSR 168 and JSR 286 here.

 JSR 168:

  • Only markup caching is supported. Resources are not accessed through a separate life cycle method.
  • Only "Expiration" cache is supported.
  • The cache is per user client and not shared across users.
  • The cached content is expired after a pre-defined (in portlet.xml) period, or as set in the portlet (programatically).
  • The expired cache is deleted and a fresh markup is fetched by calling the render method

JSR 286:

  • Resources can be cached. A new life cycle method serveResource() has been introduced which allows access to the PortletContext object apart from providing more control for the portlet developers.
  • "Validation" caching is supported along with "Expiration" caching. After the cache has expired the portlet has the option to check if the cache is still valid and indicate that the cache can be reused. To enable this, ETag has been introduced, which is similar to how the browsers, which conform to HTTP 1.1, perform caching. Once the cache has expired the Portlet Container calls the render/serveResource method with the ETag set in the RenderRequest/ResourceRequest, which the portlet can access and check if the cache is still valid. If the cache is still valid, then the portlet can set the USE_CACHED_CONTENT property in the response, and the new expiration time.
  • Cache scope has been introduced, which when set to "public" indicates that the cache can be shared across users. The default value is "private" which behaves like the JSR 168 caching where the cache is per user.

The introduction of ETag ensures that the browser can be leveraged to cache resources and markup. With the new features of public sharing of caches, resource caching, validation caching and leveraging browser caching,  the performance of aggregation of portlets by a portal can be seen to increase significantly.

Friday Jun 08, 2007

Browser caching

Browser caching has been taken for granted for so long, that I had not had an opportunity to explore it. Recently, I went through it for leveraging the cache of the browser and I want to put together the findings here :

    Expiration caching -
        The browser caches contents of a page (with the key as the url) for a predefined amount of time, which is indicated in the HTTP Response headers. After this time the browser sends a request to the server, to check for fresh contents.

     Validation caching -
          With HTTP 1.1 a new tag called the Entity Tag (ETag) is introduced, which is opaque to the browser (i.e., just stored by the browser). The browser does not do anything with the ETag but just sends the value as "If-None-Match" HTTP Request header. The server can utilize the ETag by sending a value which identifies the contents of a page, for instance, the userId so that the cache is valid for the user's session. On receiving the ETag value in the "If-None-Match" header, the server can validate whether the contents in the browser cache are still valid, for instance, now the server knows that the user has logged out, and so the cache is invalid, and the fresh contents can be sent back.

    The typical steps involved are : 

  1. The browser caches contents of a page if the HTTP Response's header indicates so. This might be through setting the "Expires" header or the new "Cache-Control: max-age=number_of_seconds" header. This provides the period till when the cache is valid.
  2. The browser uses this cache (without sending a request to the server) when the Back button, or the Forward button is clicked, and when accessing the History or Bookmarked url, provided the cache has not expired.
  3. If the Refresh button is clicked, then the browser sends a request to the server since it is an explicit request by the user to reload the page. The HTTP Request header "If-Modified-Since" will have the time period which the server can check against. The server thus has an opportunity to send fresh contents. But if the cached contents are still valid, then the server need not send any body in the response but just send a 304 status in the HTTP Response. If a 304 status is seen by the browser, the browser's cache is reused. If an ETag was sent in the original HTTP Response (ETag: exampleETagValue) then the browser sends this value as "If-None-Match" conditional header in the HTTP Request along with the "If-Modified-Since". As explained before the server can validate the cache by checking whether the ETag is still valid or not.
  4. If the cache has expired (due to the expiration period being
    completed, or due to explicit cache clearance by the user), then the
    server must send a response containing the content. For such a request, the conditional HTTP Request headers will not be present.
I think this about covers the basics of expiration and validation caching in HTTP 1.1 used by the browsers. If you have any contradictory or supplementary information, please do let me know, as I'm new to this as well.




« April 2014