[feature] Set cache headers

[eddy-geek]

It seems that tiles are not cached (trying on latest chrome, linux)

Looking at others they all set cache-control:

• OpenStreetMap: cache-control: max-age=604800, stale-while-revalidate=604800, stale-if-error=604800
• OpenTopoMap: Cache-Control: max-age=439803
• Swisstopo: cache-control: public, must-revalidate, max-age=3600
• IGN: access-control-max-age: 43200 etc

[bdon]

Are you using a reverse proxy in front of the go-pmtiles http server such as nginx or caddy?

We can add some configurable settings for Cache-Control, but it may be hard to make it flexible enough for all use cases. In any case: real, production use of the go-pmtiles server will likely need SSL termination somewhere to support HTTP/2, so there are two general approaches:

1) keep go-pmtiles minimal with the expectation that it is used in conjunction with a frontend server like nginx or even structure it as a Caddy plugin - that server can handle the more detailed production HTTP stuff like SSL, caching headers, CORS and eTags 2) Expect that go-pmtiles serves tiles directly to the browser with no intermediary, in which case we should design a way to configure all that; but this is a significant increase in scope

For an example of a parallel project to accomplish almost the same thing, see https://github.com/consbio/mbtileserver

[eddy-geek]

You are right. I am inded using an nginx reverse proxy for https, and I made it add aggressive Cache-Control headers with the last line here:

location /tile/ {
    proxy_pass  http://127.0.0.1:8077/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    add_header Cache-Control "max-age=31536000, stale-while-revalidate=31536000, stale-if-error=31536000" always;
}

[bdon]

In https://github.com/protomaps/go-pmtiles/commit/82ab855965337a9497eb6d1ff1026c125b8c2a7d I added a note that it's recommended to run go-pmtiles behind a reverse proxy.

We could add more HTTP and SSL related configuration to the go code, but it will likely never be enough to cover all production situations, and programs like NGINX are well established and specific to that job. The header configuration I'm leaving in is related to --cors since that's necessary for using go-pmtiles on localhost.

Do you think this is a good enough approach? One counterexample I can think of is if HTTP headers are customized on the upstream storage system like S3 that are then passed down in tile responses, but I'm having a hard time coming up with a specific need for this.

[eddy-geek]

Frankly I don't have a strong opinion.

• Against: it was not that easy to set up nginx with letsencrypt (challenges failing for no obvious reason...), and it was one more tool to learn to configure, so I can see the value in the batteries included approach (that it seems mbtileserver above is taking)
• For: KISS, and maybe it should not be your highest priority at this stage of the pmtiles project? ;-)

A random idea, maybe collaborate with that mbtileserver project to share this common "boilerplate"?

Anyway, as a user, I have it working with nginx now, so feel free to close this :-)

[bdon]

@eddy-geek in my experience Caddy is a good nginx alternative with a simple way to set up TLS. But as you can see from the configuration for mbtileserv, certificates are inherently complex so I'd prefer to keep them out of this code, KISS indeed.

Thanks!