Use the same cache-control header for all non-live requests.

[thruflo]

This is one suggested change partly based on the discussion in #2050.

Currently, responses to non-live requests with a -1 offset have:

cache-control: public, max-age=604800, s-maxage=3600, stale-while-revalidate=2629746

Whereas any other offset gets:

cache-control: public, max-age=60, stale-while-revalidate=300

The purpose of the lower cache duration for non -1 offsets is to enable more request-efficient data loading over time. So instead of having a long cache duration on:

insert a, b
GET offset -1 => [a, b]

insert c
GET offset 0_0 => [c]

insert d
GET offset 1234_5678 => [d]

By invalidating the cache of the second and third requests, a client coming along later will get the data in two requests:

GET offset -1 => [a, b] // still the same because cached for a longer time
GET offset 0_0 => [c, d] // compacted

This makes data loading more efficient over time for new clients. However, it also causes earlier clients to invalidate and re-fetch data that they've already synced into their private cache.

There is a solution for this and we're already using it on the -1 request: set a high max-age and / or stale-while-revalidate and a low s-maxage.

cache-control: public, max-age=604800, s-maxage=3600, stale-while-revalidate=2629746

This will allow shared (i.e.: reverse proxy / CDN) caches to revalidate and serve compacted responses after s-maxage=3600 whilst allowing private caches (browser clients) to regard the response as fresh for max-age=604800 and actually keep using whilst offline for a maximum of stale-while-revalidate=2629746.

Note lastly that this "same header for all non-live requests" is what's implemented in #2061 for 304 responses. So this suggestion also aims to standardise the cache headers between an initial 200 and subsequent 304 responses.

[thruflo]

Note, please wait for @KyleAMathews to comment and approve/revise/reject the approach before implementing.