Caddy support! (was: Why is Caddy not supported?)

[mholt]

The Protomaps docs say:

Caddy has known issues with serving large (> 5 GB) archives to particular browsers and is not officially supported right now.

Can you elaborate?

[bdon]

@mholt it works now! I haven't updated it for at least a year or two - I think what I traced was an issue in the Go standard HTTP library that was taking a huge amount of time inside the HTTP Byte Serving implementation (not related to Caddy code itself), but I recently stood up a new server using Caddy and it seems to not be an issue anymore.

Updating it now to:

• Caddy is highly recommended for serving PMTiles because of its built-in HTTPS support. Use the file_server configuration to serve .pmtiles from a static directory.

BTW, I'm going to publish some docs for "serverful" deployment soon and I'll recommend running Caddy as a reverse proxy in front of https://github.com/protomaps/go-pmtiles. This is for serving ZXY tile endpoints and not byte ranges, which can be faster and more compatible with frontends. I think letting Caddy own SSL termination and header configuration is much better than reproducing all of that in go-pmtiles code - is there an advantage to writing a module instead?

[mholt]

@bdon Ah, excellent!! Thanks for checking again. I'm a big fan of the Protomaps project after just learning about it last week.

BTW, I'm going to publish some docs for "serverful" deployment soon and I'll recommend running Caddy as a reverse proxy in front of https://github.com/protomaps/go-pmtiles. This is for serving ZXY tile endpoints and not byte ranges, which can be faster and more compatible with frontends. I think letting Caddy own SSL termination and header configuration is much better than reproducing all of that in go-pmtiles code - is there an advantage to writing a module instead?

Yeah, absolutely -- if go-pmtiles has an HTTP handler, you could easily turn that into a Caddy module with a few lines of boilerplate you can copy paste from our Extending Caddy docs.

[bdon]

I spent some time on this, and this is still a high priority! After looking at the Caddy Plugin architecture I think a reverse proxy is still the way to go. A Caddyfile config block could look like this:

tiles.myapp.com {
  route /foo* {
     header {
        Access-Control-Allow-Methods "GET"
        Access-Control-Allow-Origin https://myapp.com
      }
      pmtiles_proxy {
         bucket s3://my_bucket?region=us-west-2&endpoint=https://s3.my-objectstorage.com
         cache_size 2048
      }
  }
}

The puzzle I haven't solved in the above is how to pass credentials to the s3 bucket in the caddy plugin. hardcoding AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY_ID in the Caddyfile seems like bad design, and putting them in the root-level environment also seems bad.

The alternative is to use reverse_proxy:

tiles.myapp.com {
  route /foo* {
    header {
      Access-Control-Allow-Origin https://myapp.com
    }
    reverse_proxy :8080
  }
}

Where go-pmtiles serve is on 8080 with minimal privileges, configured however the administrator wants. The downside here is that if you wanted to serve multiple buckets, each at a different prefix: S3 on /foo , GCP on /bar, you'd need N reverse proxies and N processes for N prefixes... but maybe that's OK.

[mholt]

Personally, I'd go with the first solution, and use environment variables for the credentials. What is the concern with setting environment variables, exactly?

[bdon]

Thanks for the suggestion - passing environment variables into Caddyfiles wasn't something I was familiar with before, I'll investigate. I guess the first solution could look like this to accommodate multiple credentials instead of the implicit reading of AWS_ACCESS_KEY_ID... that https://gocloud.dev does:

pmtiles_proxy {
   bucket s3://my_bucket?region=us-west-2&endpoint=https://s3.my-objectstorage.com
   access_key_id {$OBJ_STORAGE_ACCESS_KEY_ID}
   secret_access_key {$OBJ_STORAGE_SECRET_ACCESS_KEY}
   ...
}

using caddy environment variables... does that seem sane or off?

[mholt]

^^ exactly, that's a great way to do it. The only thing is this DOES allow users to just paste the credentials right into the Caddyfile. But honestly, that isn't always bad, and I do it for some of my own sites because I don't commit the config to source control or publish it anywhere or collaborate with teams where credentials need to be scoped, etc.

You could require they go in specific env vars and not allow them to be put into the config, but then you're limited to just one set of credentials, so if someone wanted to set up 2 proxies, well, you need to be clever with a naming scheme for env vars, or... it just gets messy.

So anyway I recommend the way you're doing it, yeah. 👍

[bdon]

I got a basic plugin working locally, it was simple to implement! Have some outstanding parts I haven't figured out yet, which I'll continue in this issue: protomaps/go-pmtiles#85