WEBVTT 00:00.400 --> 00:03.040 Welcome back to the Knowledge Portal Video series. 00:03.220 --> 00:10.510 So in the last module we were discussing about the date and the expired header and how they help cache 00:10.510 --> 00:16.960 to know till what time it should store a document which should be considered fresh. 00:18.500 --> 00:21.800 However, the expired header does the basic job. 00:21.800 --> 00:29.840 Still, it is not a very ideal solution as we consider a modern internet to have. 00:30.620 --> 00:39.830 And this was the reason why in Http 1.1 protocol a new header called as cache control was introduced. 00:42.810 --> 00:46.440 So revising the date and expire header again. 00:47.370 --> 00:50.180 We have already seen it in the earlier modules. 00:50.190 --> 00:54.450 If we subtract the both of them, we can find that here. 00:54.450 --> 00:58.110 The timings are the same, even the month is the same. 00:58.110 --> 01:00.390 The only difference is the day. 01:00.750 --> 01:11.040 So if we conclude these two values, then we can find out that the document expiration can be considered 01:11.040 --> 01:12.810 as 24 hours. 01:13.170 --> 01:22.860 And this was a basic way for cash to know that how much time it should store a document for before revalidating 01:22.860 --> 01:24.210 it with the origin server. 01:27.160 --> 01:36.700 So the modern Internet has become much more complex than it was thought when the Http 1.0 protocol was 01:36.700 --> 01:37.300 designed. 01:38.740 --> 01:40.600 So we have already seen that. 01:41.640 --> 01:48.750 A particular response can be cashed either by a cache server which can be at the intermediary node, 01:48.780 --> 01:53.370 or it can also be cached on the browser side. 01:54.000 --> 02:01.770 So all the modern browsers have their own caching mechanism where a cache response can be stored either 02:01.770 --> 02:05.970 in the memory as well as well as in the disk. 02:07.750 --> 02:16.810 So in the expires header, there was no way of specifying if a response should be stored in explicitly 02:16.810 --> 02:17.710 in this. 02:18.500 --> 02:23.810 Or explicitly in the intermediary node or in the caching node. 02:24.320 --> 02:31.970 However, with the cache control header, a origin server can explicitly specify whether a response 02:31.970 --> 02:39.260 should be either be stored in the intermediary proxy or it should be stored in the client side. 02:40.410 --> 02:42.060 Cache proxy server. 02:43.710 --> 02:50.050 So let's look into the cache control directives that it will become much more clear. 02:50.070 --> 02:55.410 So these are the six directives which comes along with the cache control headers. 02:57.170 --> 02:59.870 So the first one is no store. 03:00.320 --> 03:05.540 The no store means do not store this particular response anywhere. 03:05.840 --> 03:08.360 So by anywhere, I mean. 03:09.360 --> 03:14.130 The intermediary proxy as well as the browser cache. 03:14.280 --> 03:17.340 So this can be considered as anywhere. 03:20.250 --> 03:23.520 The second directive is no cash. 03:23.790 --> 03:28.410 So no cash basically means you can store the cash. 03:28.860 --> 03:34.890 So the cash can be stored either at an intermediary or the browser side. 03:35.190 --> 03:40.170 However, before sending the response. 03:40.530 --> 03:44.790 So if the cash is stored in the intermediary proxy over here. 03:45.000 --> 03:47.280 So if a client sends a request. 03:47.550 --> 03:53.940 So before a cache can send the response back, it should revalidate with the origin server. 03:53.970 --> 03:59.190 If the response is the latest one or is the fresh one. 03:59.970 --> 04:03.150 And this is what is considered as no cash. 04:06.080 --> 04:09.780 The third directive here is max, age zero. 04:09.800 --> 04:13.760 So Max, age zero we have already seen corresponds to the. 04:14.860 --> 04:20.410 Maximum age in seconds for which a document should be considered valid. 04:22.230 --> 04:25.830 Then is the s hyphen max at zero. 04:25.860 --> 04:30.900 Now s hyphen max is zero is explicitly for the intermediary proxy node. 04:31.320 --> 04:34.380 This is not for the client side caching. 04:36.950 --> 04:40.400 Then we also have the must revalidate header. 04:40.580 --> 04:44.860 So must revalidate is somewhat similar to no cache. 04:44.870 --> 04:48.500 We will be talking about the difference in the upcoming module. 04:48.530 --> 04:58.250 However, if you just have an overview, must revalidate means that a cache must revalidate the document. 04:59.160 --> 05:00.870 After it is expired. 05:02.290 --> 05:03.910 To back to the origin server. 05:05.850 --> 05:09.410 And there is one more header college pragma, no cache. 05:09.480 --> 05:14.730 So this basically is used for backward compatibility. 05:14.730 --> 05:18.910 So pragma no cache is somewhat similar to the cache control, no cache. 05:18.930 --> 05:27.030 However, pragma no cache is specifically for the Http 1.0 based applications or browsers. 05:28.250 --> 05:29.030 So. 05:31.260 --> 05:33.770 Coming back to our favorite sketch. 05:34.140 --> 05:38.940 So let me show you our nginx configuration. 05:43.080 --> 05:49.550 So here if you see four dot PNG file we have already added expires as one hour. 05:49.590 --> 05:54.660 So this means cache can store this particular response for one hour. 05:55.470 --> 05:57.180 So if we do a curl. 05:59.000 --> 06:01.700 For example.com. 06:03.240 --> 06:04.620 Logo dot PNG. 06:06.070 --> 06:06.520 So sorry. 06:06.580 --> 06:07.590 It should be Http. 06:09.490 --> 06:10.630 I'll say. 06:21.910 --> 06:23.680 Logo dot PNG. 06:27.290 --> 06:29.150 This is the third time making a mistake. 06:30.800 --> 06:32.300 Slow and steady wins the race. 06:35.490 --> 06:37.050 Okay, so this is perfect. 06:39.330 --> 06:48.180 So here you see the Nginx is including both the expires header as well as the cache control header. 06:48.690 --> 06:58.170 Now it's important to know that cache control header followed by max hyphen H specifies the maximum 06:58.170 --> 07:03.480 age of a document that can be considered as fresh in terms of seconds. 07:06.540 --> 07:14.340 The reason why expires and cache control header both are introduced by Nginx is because there can be 07:14.340 --> 07:22.950 some browser or some application which is still following the legacy Http 1.0 based protocol and for 07:22.950 --> 07:28.380 backward compatibility for them to understand the expires header has been introduced. 07:28.740 --> 07:35.310 However, if both expires as well as cache control headers are introduced, the modern browser will 07:35.310 --> 07:40.120 just read the cache control it will not consider expire header. 07:40.140 --> 07:42.810 So this is something which is important to know. 07:43.600 --> 07:49.690 So this is it about the basics of cache control headers and why they are introduced. 07:49.930 --> 07:53.920 We'll be talking more about them in the upcoming lectures. 07:54.340 --> 07:59.560 So I hope this basic information has been informative for you and I'd like to thank you for viewing.