Caddy and Server/Product Tokens

I noticed when doing my own embedding of Caddy that the server only uses the caddy.AppName and caddy.AppVersion variables to identify itself over the FCGI protocol, and not as the Server header Product Token. I’ve submitted the PR below to resolve this.

I’d like to start a discussion around the inclusion of more version information for plugins, and identifying them externally to Caddy with the Server headers Product Tokens. The externalisation of which plugins the server uses is something not everyone wants so a new directive would need to be added. It also seems’ as though caddy.DescribePlugins() should output the version of the plugin its using.

The question is really how would the maintainers and plugin authors like the versioning to work. Should we automatically include such information during the build process. I was personally thinking of the tag and commit ref., should be enough to identify the exact version of code being used?

What other web servers do:

Relevant RFC docs:

Example of possible DescribePlugins() output:

#caddy -plugins

Server types:

Caddyfile loaders:

Other plugins:
  http.filemanager (#cf1b563) 
  http.ipfilter (#7fd8aa5)
  http.jwt (v1.0.1#1509a31)
  http.mailout (v1.0.0#f289025)
  http.ratelimit (#164fb91)

Example of possible Server header:

Server: Caddy/0.9.0#f28af63 FileManager IpFilter JWT/v1.0.1 Mailout/v1.0.0 RateLimit

Thanks for starting this discussion Simon! I wondered when this might come up. :slight_smile:

There’s a couple different topics here; one is the versioning of plugins (which I definitely agree is a problem in the long run if neglected) and the other is the disclosure of build information to any HTTP clients.

I am in favor of the first, not so much the second.

In favor of versioning plugins:

  • This is going to get out of hand in the long run. I can smell it coming. Like impending doom. I’m not in a hurry to improve on the situation right now, but by 1.0 we need a better system in place for reproducible builds, plugin versioning, etc. This involves a new build server (I have some plans for it) and requires that plugin authors adhere to some sort of standard/guidelines so that their versioning and deployment is compatible.

Not in favor of revealing build information:

  • HTTP clients do not need to know this; period. Let’s not disclose what we do not need to. If there is a vulnerability, we should not be broadcasting it at least. If we need to reveal special information about the internals of Caddy, we can do so to authorized users at an authenticated endpoint, perhaps with Caddy’s API (in planning phases).