[Fleet][EPM] Assets responses will forward any EPR cache-control header

[jfsiii]

closes #83631

Problem

Assets are served with a cache-control header that prevents any caching

Root cause

Likely from this code

kibana/src/core/server/http/http_tools.ts

Lines 40 to 43 in 2a365ff

	cache: {
	privacy: 'private',
	otherwise: 'private, no-cache, no-store, must-revalidate',
	},

Also based on these tests, it seems this is default/expected behavior

kibana/src/core/server/http/integration_tests/router.test.ts

Lines 510 to 520 in b3eefb9

	it('does not allow responses to be cached by default', async () => {
	const { server: innerServer, createRouter } = await server.setup(setupDeps);
	const router = createRouter('/');
	router.get({ path: '/', validate: false, options: {} }, (context, req, res) => res.ok());
	await server.start();
	await supertest(innerServer.listener)
	.get('/')
	.expect('Cache-Control', 'private, no-cache, no-store, must-revalidate');
	});

Proposed solution

Set the header via the response handler as shown in this test:

kibana/src/core/server/http/integration_tests/router.test.ts

Lines 522 to 536 in b3eefb9

	it('allows individual responses override the default cache-control header', async () => {
	const { server: innerServer, createRouter } = await server.setup(setupDeps);
	const router = createRouter('/');
	router.get({ path: '/', validate: false, options: {} }, (context, req, res) =>
	res.ok({
	headers: {
	'Cache-Control': 'public, max-age=1200',
	},
	})
	);
	await server.start();
	await supertest(innerServer.listener).get('/').expect('Cache-Control', 'public, max-age=1200');
	});

This PR

If this registry response contains a cache-control header, that value is included in the EPM response as well

In master, which points to epr-snapshot

which matches https://epr-snapshot.elastic.co/package/apache/0.2.6/img/logo_apache.svg

or using epr.elastic.co,

which matches https://epr.elastic.co/package/apache/0.2.6/img/logo_apache.svg

Checklist

Should I add any tests for this? What kind(s) if so?

• Unit or functional tests were updated or added to match the most common scenarios

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 2dfa0f2

Metrics [docs]

✅ unchanged

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[ruflin]

What happened exactly before this change? Every time the browser requested the image, Kibana requested it again from the CDN?

After installing a package, is the image served from the local package cache or also the CDN?

[jfsiii]

What happened exactly before this change? Every time the browser requested the image, Kibana requested it again from the CDN?

Yes. Every view caused the browser to make a request to Kibana, which then made a request to the Registry.

After installing a package, is the image served from the local package cache or also the CDN?

I'm not entirely clear on what you mean by "local package cache". The contents do not come from server memory if that's the question.

All files, regardless of installation status, are fetched from the Registry.

What's changed here is Kibana now includes the Registry response's cache header in the response to the browser. This way, the browser will use it's cache and rules to avoid even making a request to Kibana.

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ruflin]

Tested this locally and seems to do the tricky. Image loading is now much quicker and contains the cache headers.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 83680 or prevent reminders by adding the backport:skip label.

[kibanamachine]

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.