Metrics and health endpoints should return Cache-Control: no-store, no-cache, must-revalidate

[tjquinno]

Environment Details

• Helidon Version: 2.x
• Helidon SE or Helidon MP
• JDK version:
• OS:
• Docker version (if applicable):

---

Problem Description

Responses from the health and metrics endpoints depend on highly-changeable conditions within the server and, therefore, caching of such responses should be discouraged.

Currently, these services do not include the most vigorous denials of caching.

Proposed solution

This enhancement would have each of those services return Cache-Control: no-store, no-cache, must-revalidate on every response.

(Very useful reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)

In theory, no-store would be sufficient because that means "don't cache this anywhere, ever."

The "no-cache" setting allows caching as long as the client revalidates before reusing the cached content. Apparently certain clients do not honor certain of these settings, so responding as proposed above would be most likely to prevent caching.

Alternative

An alternative would be for metrics and health to "remember" the prior response and its timestamp, so subsequent revalidation requests (e.g., "If-Modified-Since" request header) might lead to a 304 Not Modified response status, allowing the cached response to be marked as valid again.

But there are several responses that could be tracked this way (/metrics, /metrics/{scope}, /metrics/{scope}/{metric-name}, /health, /health/{check-type}). This tracking would be useful only if the responses were likely to remain the same over various time periods and if the payloads are sufficiently large that caching them and avoiding their retransmission would be a net win given the increase in complexity required in the server to manage this approach.

Steps to reproduce

Run a Helidon server with health and/or metrics support, access the endpoint, and inspect the returned headers.