Change 779520 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/Kartographer@master] [WIP] Match cache headers to response

https://gerrit.wikimedia.org/r/779520

Requests with the latest revision can also be cached because the group ids are unique hashes that never change. Something like 5 minutes sounds like a good starting point.

This is only true if the group id was passed as a parameter (for example, https://de.wikipedia.beta.wmflabs.org/w/api.php?action=query&prop=mapdata&titles=Maptests&mpdgroups=_57e8f8e52ea263afe4d4ed2bb57dd4f5b14582c0 vs https://de.wikipedia.beta.wmflabs.org/w/api.php?action=query&prop=mapdata&titles=Maptests). I'll update the task description.

In case of an error no caching should happen, as the error might be resolved the next second.

It's a balance: if we allow no caching at all for errors, then an URL with an intentionally incorrect groups parameter becomes an attack vector that can cause unlimited requests to the backend. If we give too long a value, then users may see broken maps for no reason. What about a compromise such as 5 seconds?

The precedent in MediaWiki-core is to set max-age to 0, so it's also fine to ignore the DoS issue and leave at defaults.

I discovered a problem in our assumptions, which should be addressed generally: The contents of a past revision are not constant because transclusion is not tied to specific revisions. If the mapframe is generated by a template which changes, or the mapframe content uses i18n messages or Wikidata coordinates which change (or all of the above), then a historical revision may be re-rendered with new mapframe content. Additionally, ExternalData may change and it could be surprising if the maps take some time to update.