Monday 15 December 2014

Cache Pragma Header OAM

In OAM SSO Agent configuration we have 2 caching headers:



  1. Cache Control Header
  2. Pragma Header


As per the RFC 2616, Pragma Header is their for backward compatibilty while in all the browers & client specfic system we all are using HTTP/1.1

Thus as per the HTTP/1.1 standard Cache-Control Header is in use.

So as the OAM Webgate 11g is developed as per the HTTP/1.1 statndard. Thus it makes use of this Cache-Control Header & Pragma is their just for backward compatibilty.

That's why you see that they both have same values & Pragma Header uses the same value as that of Cache-Control Header value.





Some more info related Cache Control Header:


HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
Useful Cache-Control response headers include:
  • max-age=[seconds] — specifies the maximum amount of time that a representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. [seconds] is the number of seconds from the time of the request you wish the representation to be fresh for.
  • s-maxage=[seconds] — similar to max-age, except that it only applies to shared (e.g., proxy) caches.
  • public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically private.
  • private — allows caches that are specific to one user (e.g., in a browser) to store the response; shared caches (e.g., in a proxy) may not.
  • no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.
  • no-store — instructs caches not to keep a copy of the representation under any conditions.
  • must-revalidate — tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.
  • proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.

References:

https://www.mnot.net/cache_docs/


Enjoy :-)

No comments:

Post a Comment