Webseal provides a capability to cache static web contents in order to increase the response time of a transaction. Two things which drive the caching behavior are
- Response headers -> determines if the content is eligible for the caching. To put in simple words based on few response headers webseal decide whether a image or a javascipt or a CSS file will be stored in Webseal cache memory or not.
- Request headers -> determines if requested resource will be served from the webseal cache or request will be passed to the backend server.
As far as Webseal is concern it is required to understand the caching at
- Webseal level
- Browser level
WebSEAL cache the contents based on the following conditions
- If request has a attribute query, it will not cache the response of such request
- If junction has –c, -C or -b supply attribute, it will not cache the contents of such responses
- WebSEAL does not cache the contents of the user if user is authenticated using SPNEGO or BA
Details on enabling caching in WebSEAL can be found at the IBM site.
Most critical part to understand caching is to understand how browser handles the caching. Most of the browsers store the static contents like images, javascripts, CSS files and html pages in browser’s local cache. When a request is made to the same resource again browser tries to use the content in the local cache and it save lot of round trips to the WebSEAL and backend servers.
The reuse of contents from the browser’s local cache depends on “Expiration” parameter of the content. If content stored in browser’s cache has “expiration” value set to future date browser will reuse the same content and will not send any request to WebSEAL or backend server. If “expiration” date is not set browser will send request to backend sever to get the latest contents.
Another parameter which impact browser caching is “Last-modified” timestamp. If Last-Modified time stamp is set for the content in browser’s cache and “expiration” date is not set, it will send a request to the WebSEAL/Backend server with “if-modified-since” header. This header will carry last-modified timestamp. Upon receiving a request from browser with if-modified-since header, webseal will compare the timestamp of if-modified-since header with the contents stored in the WebSEAL cache. If modified date of the content in WebSEAL cache is same as that of if-modified-since it will send a “304 HTTP Response” to the browser. This response will not contain any content other than HTTP headers. It tells browser that contents in browser cache is good to use.
If browser is sending the request to WebSEAL and requested static contents are not present in the browser’s cache or “last-modified” date is not present, it will not send any “if-modified-since” header to the WebSEAL. If WebSEAL find the contents in WebSEAL’s cache it will return HTTP response 200 and send the contents to the browser without contacting backend server.
Details of the transaction can be seen in the WebSEAL by enabling pdweb.debug trace. It shows complete flow of every transaction
Browser -> PD
PD -> Backend
Backend -> PD
PD -> Browser
Most critical part to understand caching is to understand how browser handles the caching. Most of the browsers store the static contents like images, javascripts, CSS files and html pages in browser’s local cache. When a request is made to the same resource again browser tries to use the content in the local cache and it save lot of round trips to the WebSEAL and backend servers.
The reuse of contents from the browser’s local cache depends on “Expiration” parameter of the content. If content stored in browser’s cache has “expiration” value set to future date browser will reuse the same content and will not send any request to WebSEAL or backend server. If “expiration” date is not set browser will send request to backend sever to get the latest contents.
Another parameter which impact browser caching is “Last-modified” timestamp. If Last-Modified time stamp is set for the content in browser’s cache and “expiration” date is not set, it will send a request to the WebSEAL/Backend server with “if-modified-since” header. This header will carry last-modified timestamp. Upon receiving a request from browser with if-modified-since header, webseal will compare the timestamp of if-modified-since header with the contents stored in the WebSEAL cache. If modified date of the content in WebSEAL cache is same as that of if-modified-since it will send a “304 HTTP Response” to the browser. This response will not contain any content other than HTTP headers. It tells browser that contents in browser cache is good to use.
If browser is sending the request to WebSEAL and requested static contents are not present in the browser’s cache or “last-modified” date is not present, it will not send any “if-modified-since” header to the WebSEAL. If WebSEAL find the contents in WebSEAL’s cache it will return HTTP response 200 and send the contents to the browser without contacting backend server.
Details of the transaction can be seen in the WebSEAL by enabling pdweb.debug trace. It shows complete flow of every transaction
Browser -> PD
PD -> Backend
Backend -> PD
PD -> Browser
