Q8: Cache Directives

[00:00:00]
>> Okay, question 8. Match the caching directives to their definitions. So we have no-cache, must-revalidate, no-store, private, and stale-while-revalidate. And then we have one validates a stale response with the origin server before using it. Two, serves stale content while validating the cached response with the origin server. Three, doesn't cache any part of the request or response.

[00:00:25]
Four, validates the cached resource with the origin server before using it even if it is still fresh, and five, prevents caching on shared caches. All right, let's see what the answer is. So we have A, no-cache validates a cache response with the origin server before using it, even if it's still fresh.

[00:00:48]
Must-revalidate validates is still responds with the origin server before using it. No-store doesn't cache any part of the request or response. Private prevents caching on shared caches. And stale-while-revalidate serves stale content, while validating the cache response with the origin server. So let's first go to no cache. So first, when we make that initial request, there's nothing cached yet.

[00:01:12]
We get it from the origin server, and then it gets cached in a private cache, like browser cache. You can see that in most cases, a server will also return something called an ETag. This is a unique identifier that tells, okay, this resource has this unique identifier. And this is important for the future, if we ever update that resource, if we change any of the contents, it'll have a different hash, it'll have different ETag.

[00:01:35]
But caches can use this to ensure that what they have cashed is still the most up-to-date resource. So with no-cache, it's fresh now, the response can get returned to the client after making that request. So now the next time we request it, it won't just get it from cache instantly, it'll first make sure with the origin server.

[00:01:57]
Hey, I have this cached version with the if-none-match, this is my ETag, is that still valid? Is that still the most up-to-date resource? And then the server can just quickly respond with the 304 not modified. It's like, yeah, this is fine, you still have the most up-to-date resource.

[00:02:12]
So this is of course much faster cuz it doesn't have to do actually download that resource, it just responds with that header. Now, if we update the resource, different ETag is like, hey, I have this one, then servers are like, no, no, you should get a new one.

[00:02:24]
It'll return a cache control again with a no-cache. New ETag, and it updates the cache, so that's no-cache. So that's important to remember because no-cache doesn't mean that it's not caching despite its kind of I don't know the deceptive name. It just means that it will always make a request to the origin server first before using the cached version.

[00:02:44]
So then we have the must-revalidate. So again, we just make that request to the origin server. And here you can see the must-revalidate cache control and also a max age, which is usually included. So the max age does defines how long a resource is fresh for, like fresh in the cache.

[00:03:00]
So now when after ten seconds it becomes stale, and the cache says, it's like hey it's stale, sorry I shouldn't have removed those things. But anyway, when it's stale, it makes another request to the origin server to update that resource. I think it's kind of the most straightforward caching policy.

[00:03:19]
So now if we update it, we still have the max age of ten. So it's still fresh, even though the ETag in the cache doesn't match the ETag on the server, but it's still fresh in the cache. So I can still just use that response. And only when it then becomes stale again will it make that make a request again and update the resource in cache?

[00:03:41]
This makes more sense when we always talk about the stale while revalidate. So yeah, but then we have the no store, which is very easy, it doesn't cache any part. This is perfect for private data, maybe some financial data, anything that's user specific, sensitive data that shouldn't get cached or should have the no-store policy.

[00:04:03]
And then we have private, which prevents caching on shared caches. So this kinda makes more sense when we also have a CDN in between, right? So normally, a CDN might intercept the response and just cache it on their servers as well. With private, we can make sure that that doesn't happen.

[00:04:19]
It only caches it on the user's HTTP cache. And this is perfect for user-specific data, like maybe some dashboard or anything that could be user-specific, not shared with multiple users, or should get the private policy. And then lastly, we have the stale-while-revalidate, which serves the stale content while validating the cache response with the origin server.

[00:04:42]
So it's a bit similar to the must revalidate. So we first get that, response with the max age, and then the still while revalidate, I'll talk more about these numbers a bit later. But now the response is stale, and where the must-revalidate wouldn't return the stale response.

[00:04:57]
This one does, it returns that stale response first, but in the background it makes a request to the origin server to revalidate that resource. In this case it wasn't modified, but it will still like update the cache now to be fresh again because it has a new max age value, so this is perfect because the user doesn't really see that, like, the user doesn't experience any latency here.

[00:05:19]
It just gets that stale resource back while that server updates the cache response. And this is different from the must-revalidate, where the user might see some latency because it first had to request the fresh resource from the origin server again. So this is perfect for content where you don't really care if it's stale, like maybe some blog post or something.

[00:05:38]
And it's, okay, well this typo is fine, people can still see that typo for once, but maybe the next time they refresh the page you know that. The browser has updated that resource in its cache in the background. Yeah, so stale-while-revalidate, it's basically, you normally have like the max age.

[00:05:52]
So that is the age that the content is still fresh, and then we have the stale -while-revalidate period. And that's essentially the period where we tell the browser like, hey, this is the time after max age has expired, that it's still okay to use that stale resource. Cuz if it's been stale for a year, we don't wanna use that stale resource, then it should instantly make a request to the origin.

[00:06:14]
But if it's been stale for 30 seconds, and we're that's fine, that's doable. Anything after that, then don't serve the stale response, then just fetch it from the origin right away. So in that case, it's kind of more of like a must-revalidate policy.
>> Does it send hash of the current cached data to do their validation before caching?

[00:06:35]
>> I think maybe what you're asking is if it hasn't updated, will it send the hash again? Well, in this case, it has updated. Well, even if it sends a 304 not modified, it will usually still send that ETag, and also it will send the cache control headers again.

[00:06:53]
So it will again have that max age, which refreshes the response that's already in cache to be fresh again, even if it was still prior to sending that request.
>> So this question is related to how the browser actually validates the cache?
>> I'm not sure about the algorithm, if that's what you're asking with ETag.

[00:07:18]
I was just trying to get that. Here, the if-none-match, right? Yeah, that's a response, [LAUGH] or a request header. So it's just like the server kind of, sorry, I'm trying to get that arrow again. Okay, there we go. Okay, cool, so the request header contains the if-none-match, and it's up to the server to then see like, okay, well that's not the ETag that I currently have for that resource.

[00:07:51]
So it's not really up to the browser to do anything with that. It's up to the server to then decide, now I'm going to serve new content instead of returning a 304 not modified, I'm going to return to 200, okay, with the actual resource as a response. I hope that answers the question?

[00:08:10]
I'm not sure what the browser does internally to then change the hashes within the HTTP cache, that's some internal browser.
>> Yeah, thanks, I got it. ETag is a unique value like a hash?
>> Yeah, that's the hash of the resource. So anytime you change anything in the document, it will return a different hash.