When theResponseCacheStrategy is merging ESI surrogates and the master response, it treatss-maxage=0 as if nos-maxage has been set.

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

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

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

Some notes ons-maxage=0

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

According tohttps://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 betweens-maxage=0 andmust-revalidate is that a "disconnected" cache (one that cannot contact the origin server)must not use a stale response whenmust-revalidate is used, butis not prohibited from doing so fors-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 (noETag, noLast-Modified). But, as explained above, it is still important to pass on the explicit expiration time, instead of having no value for it.