HTTP Caching

Arun Rajeevan
2 min readOct 26, 2018

--

Background:
Every browser ships with an implementation of an HTTP cache.
All you need to do is ensure that each server response provides the correct HTTP header directives to instruct the browser on
when and for how long the browser can cache the response.

1. What is HTTP Caching?
The ability to store the HTTP response of particular HTTP requests and reuse it.

2. What are the advantages of HTTP Caching?
Large responses require many roundtrips between the client and server,
which delays when they are available and when the browser can process them, and also incurs data costs for the visitor.

3. Which are idempotent methods?
An idempotent HTTP method is a HTTP method that can be called many times without different outcomes.
GET, PUT, HEAD, OPTIONS

4. What Browser does when it receives an HTTP response without any Caching headers?
If no cache or age is specified, then the cache behavior is undefined: the browser’s author is free to make up his own mind as to what is correct.
Different browsers will probably behave differently.Normally, the response of Idempotent HTTP methods are cached.

5. Which are the HTTP headers associated with Caching at server side?
The Cache-control header
1) No cache storage at all
Cache-control : no-cache, no-store, must-revalidate
2) Expiration
Cache-control : max-age=<some value>

Refer this article for more: [https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching HTTP Caching explained in detail]

Problems faced in live projects because of less awareness about HTTP Caching
1)We initially missed to set the cache headers at server side. Whenever we deploy a new change in microservice, the UI was receiving the data from the Browser’s cache for all the GET requests.

2)We stored some static html, css and js files on S3 bucket so that our CEM cloud UI can be accessed from any client.
We missed to change the cache control attribute at S3 for the files. So when a browser access our Html page for the first time it caches it.
Not only the Browser, the intermediate Gateways too cache the response.
As a result, even if we replace some files in the same bucket, and we reload the page, the Browser was getting pages from its cache.
Then we cleared the browser cache but still it was getting the old files from the Gateways in between the Amazon S3 server and our machine.

--

--

No responses yet