WEBVTT

00:00:01.672 --> 00:00:03.386
When a response from your application

00:00:03.386 --> 00:00:06.243
contains sensitive data, you might want to

00:00:06.243 --> 00:00:09.005
control the caching of it, or the browser

00:00:09.005 --> 00:00:12.338
and possibly other processes that monitor

00:00:12.338 --> 00:00:15.547
the request. Caching means the data is

00:00:15.547 --> 00:00:18.671
stored and its data source can be the

00:00:18.671 --> 00:00:21.672
victim of attacks and exploits. You can

00:00:21.672 --> 00:00:24.672
instruct caching mechanisms by setting the

00:00:24.672 --> 00:00:26.338
cache-control header. Most caching

00:00:26.338 --> 00:00:29.271
mechanisms will honor it, but it's not a

00:00:29.271 --> 00:00:31.894
guarantee. It's easy to write some

00:00:31.894 --> 00:00:34.338
JavaScript to cache data in an external

00:00:34.338 --> 00:00:36.422
Redis cache, for example, and just ignore

00:00:36.422 --> 00:00:40.386
the cache-control header. Let's run the

00:00:40.386 --> 00:00:43.871
ASP.NET Core application again. It has the

00:00:43.871 --> 00:00:46.271
header already set to no-cache and

00:00:46.271 --> 00:00:48.386
no-store. The ASP.NET application has

00:00:48.386 --> 00:00:51.005
another default, private. You can easily

00:00:51.005 --> 00:00:53.671
override these defaults by setting the

00:00:53.672 --> 00:00:56.297
header using one of the methods you

00:00:56.297 --> 00:00:58.672
learned. But what do these setting mean?

00:00:58.672 --> 00:01:01.297
Public means it's okay to cache the

00:01:01.297 --> 00:01:03.422
response and caches that are from the user

00:01:03.422 --> 00:01:07.957
only, as well as shared caches. Private

00:01:07.957 --> 00:01:10.672
means it's only allowed in caches that are

00:01:10.672 --> 00:01:13.957
private to the user. No-cache means that

00:01:13.957 --> 00:01:17.005
whenever the data from the cache is used,

00:01:17.005 --> 00:01:19.529
the server must first be checked if there

00:01:19.529 --> 00:01:22.672
is a new version. And no-store turns off

00:01:22.672 --> 00:01:24.529
caching completely. These possibilities

00:01:24.529 --> 00:01:27.571
can be used in combination with all kinds

00:01:27.571 --> 00:01:30.271
of options that have to do with the

00:01:30.271 --> 00:01:33.338
expiration of the data. Max-age, for

00:01:33.338 --> 00:01:35.814
example, specifies the maximum amount of

00:01:35.814 --> 00:01:39.872
seconds after a request the data will be

00:01:39.872 --> 00:01:41.797
considered fresh. And setting max-stale

00:01:41.797 --> 00:01:44.422
lets you tell the caching mechanism that

00:01:44.422 --> 00:01:47.797
it's okay to use cached data that is past

00:01:47.797 --> 00:01:50.672
its expiration time for the specified

00:01:50.672 --> 00:01:53.672
amount of seconds.
