/health endpoint when serving

[zifeo]

useful for health checks

[bdon]

What information would this provide over making a HEAD request for root path /?

I recommend more full-fledged HTTP server functionality can be achieved by embedding the pmtiles module inside of Caddy.

[zifeo]

Just an empty GET /. We are already having a reverse-proxy in our setup, is there any other advantage to use caddy instead of pmtiles?

[bdon]

The root path of pmtiles serve already returns a 404, is that a sufficient health check? Otherwise we need to represent a resource that corresponds to no pmtiles archive.

Caddy provides reverse proxy functionality and SSL termination along with other features, so we don't need to implement any of those in go-pmtiles.

[zifeo]

Got it, we have this elsewhere in the stack so no need to duplicate :). Usually, probes follow this rule:

Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

[bdon]

It seems reasonable to change this line to https://github.com/protomaps/go-pmtiles/blob/main/pmtiles/server.go#L392 to a 204 in the case of an empty path - an empty archive name is impossible

• asking for / returns 204
• asking for /a.json returns 200 if archive a exists, and 404 if it does not
• asking for /a without a.json or another valid path is a malformed path and maybe should be changed to return 400?

[zifeo]

Seems reasonable, maybe /health/[archive] → 200 is easier to understand (not sure the json helps unless the return is actual json metadata).

[bdon]

Is your goal to determine if an archive exists, or just that the server is running? Adding another route like /health is application-specific and out of scope.

[zifeo]

Just if the server is running, whether the archive or even the tile is available is not needed.

[bdon]

in 1.12.0 https://github.com/protomaps/go-pmtiles/releases/tag/v1.12.0 the root path / now returns a 204 No Content instead of 404 Not Found.

[bdon]

Closing this as the 204 for / should be sufficient.