Showing posts with label cache pragma header oam. Show all posts
Showing posts with label cache pragma header oam. Show all posts

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 :-)