Return header information for display in browser?

1. Caddy version (caddy version):


2. How I run Caddy:

Using caddy on a raspberry pi lite OS 32bit (based on debian), its run as a service that is setup and configured via a deployment script.

a. System environment:

raspbian lite OS. using systemd to start/manage custom build of caddy with plugins (caddy-auth-portal, caddy-auth-awt)

uname -a
Linux pidev 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux

systemd managing custom build of caddy with (via xcaddy) with plugins caddy-auth-portal, caddy-auth-awt, caddy-trace

b. Command:

systemctl start caddy

c. Service/unit/compose file:


#plugin modified caddy build for auth-portal and associated plugins
#/usr/bin/caddy now linked to /opt/caddy/releases/[current build]
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
#ExecStart=/opt/caddy/bin/caddy_linux_arm7_custom run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
#ExecReload=/opt/caddy/bin/caddy_linux_arm7_custom reload --config /etc/caddy/Caddyfile


d. My complete Caddyfile or JSON config:

storage file_system {
    root    /opt/caddy/storage
http_port     80
https_port    443
}, {
# caddy-auth-portal with local db config
    log {
        level INFO
        format console
        output file /var/log/caddy/caddy.log
# caddy auth portal login
    route /auth* {
          auth_portal {
              path /auth
                  backends {
                      local_backend {
                          method local
                          path /opt/caddy/assets/conf/local/auth/user_db.json
                          realm local
# custom webapp running on port 1080 route
    route /* {
        jwt {
           primary yes
           trusted_tokens {
              static_secret {
                 token_name access_token
                 token_secret AnExampleSecretString123
           enable claim headers
        reverse_proxy http://localhost:1080
    route /version* {
           respond * "2.0.0-a" 200
    route {
           redir 302

3. The problem I’m having:

I’m trying to figure out how to use the caddy “respond” or any other function to display header information within the browser for the connected user’s request.

I’m well aware of dev tools and logging solutions, for our situation we need to have a simpler method (troubleshooting training) to quickly check what currently is being presented in a client connection.

The idea is to have caddy serve a route, “debug” for example that can be used to in real time display the current authenticated user’s header information.

I’m imagining that the entry in the Caddyfile under the server instance would look something like:

   route /debug*   {
        jwt {
           enable claim headers
        respond "[some magic string for expanding specific header values]" 200 

The jwt directive is providing the headers for the authenticated user, the question is does caddy have a way to display them or do we need to fall back to a web page programatically doing it behind the proxy?

4. Error messages and/or full log output:

I’ve not tested yet as I cant find reference other than the “Respond” documentation page. It indicates static content, I’m hoping there is a way to provide the info dynamically, or there is some other directive I’m not realizing is useful…

5. What I already tried:

Its not clear if there is some form of macro expansion for caddy that can be expressed from this configuration. If not we can fall back to a web page behind caddy to do it.

6. Links to relevant resources:

Please use the caddy fmt command to clean up the syntax of your Caddyfile, it’s quite hard to follow without consistent indentation.

I think you’re looking for request placeholders:

If you want to return all the headers, then you can probably make use of Caddy’s tenplating features to do this:

  1. thank you for the caddy fmt command!
  2. thanks for the templating pointer!
1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.