When the ResponseCacheStrategy is merging ESI surrogates and the master response, it treats s-maxage=0 as if no s-maxage has been set.

The result is that for a main and a surrogate response that both are public, s-maxage=0, the result will only be public, with no further expiration time.

https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.2 allows caches to assign a heuristic expiration time when no explicit expiration time has been given but the response has been marked as explicitly cacheable with public. Clearly, such a heuristic was not intended or desired when public, s-maxage=0 was given.

This PR ensures that s-maxage=0 is passed along with the resulting response.

Some notes on s-maxage=0

You might argue that s-maxage=0 does not make sense on a response.

According to https://datatracker.ietf.org/doc/html/rfc7234#section-3.2, s-maxage=0 is a valid setting to ensure that a cached response "cannot be used to satisfy a subsequent request without revalidating it on the origin server".

This setting can be used to keep responses in edge caches/CDNs, but to re-validate on every request. The bottom line result can still be faster (304 + response already at the edge vs. fetch response from origin).

To my understanding, the difference between s-maxage=0 and must-revalidate is that a "disconnected" cache (one that cannot contact the origin server) must not use a stale response when must-revalidate is used, but is not prohibited from doing so for s-maxage=0 (https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.4). In other words, must-revalidate is not exactly the same as (or the "right" way instead of) s-maxage=0.

In the special case of ESI (composite) responses, revalidation is not possible (no ETag, no Last-Modified). But, as explained above, it is still important to pass on the explicit expiration time, instead of having no value for it.