Caddy: Response header manipulation doesn't work on redirects

[KEANO89]

1. What version of Caddy are you running (caddy -version)?

Caddy 0.8.3

2. What are you trying to do?

Removing the response header "Server"

3. What is your entire Caddyfile?

example.org {
    tls [email protected]
    errors /var/log/example.org.err
    root /var/docker/www/example.org

    fastcgi / 127.0.0.1:9002 php {
        env PHP_VALUE "display_errors=off
                        error_log=/var/log/fpm-php.www.log
                        memory_limit = 512M
                        post_max_size=256M
                        log_errors=on
                        upload_max_filesize=256M
                        expose_php=off"
    }

    header / {
        X-Backend-Server {hostname}
        -Server
    }

    rewrite / {
        to /maintenance.html {path} {path}/ /index.php
    }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

/usr/sbin/caddy -agree -email [email protected] -pidfile /var/run/caddy.pid -log /var/log/caddy.log -conf /etc/caddy/caddy.conf

5. What did you expect to see?

No response header "Server: Caddy"

6. What did you see instead (give full error messages and/or log)?

The response header is sent on redirects (e.g. switch to https)

HTTP/1.1 301 Moved Permanently
Location: https://example.org/
Server: Caddy
[...]

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

Manipulate headers via Caddyfile, enable HTTPS so caddy redirects to it and inspect the response headers

[mholt]

Hm, indeed, the automatic HTTP->HTTPS redirects don't chain in all the middleware defined for the HTTPS version of the site. I guess I never saw a need for them and I still think that's the case but I can see why it would be useful to have the header middleware copied over. I'll see what can be done about that for 0.9.

[mholt]

I suppose one thing that could be done is to map directive names to a list of middlewares by adding a map field in SiteConfig and then populate the map from AddMiddleware() so we can just extract the middleware we want and copy that into the HTTP redirect SiteConfig.

[mholt]

Soooo that's not really possible because when a setup function calls AddMiddleware() it only passes in the middleware itself, not the name of the directive. So there's not really an easy/elegant/obvious way to map directives to the middleware they've injected.

Maybe an oversight on my part, but I also think this should work for now:

https://example.com {
    ...
    header / {
        -Server
    }
}

http://example.com {
    redir https://{host}{uri}
    header / {
        -Server
    }
}

To do what you ask would be a breaking change and maybe now is the right time to make it, but I haven't decided yet if I should, or haven't investigated enough to know if there's a non-breaking way.

[KEANO89]

Yeah that's the same workaround we came up with. This addition does the trick. So this issue is not a huge bug, but caddy is still 0.x so according to semver2.0 breaking changes are perfectly fine. Although I understand this needs reconsideration because caddy feels pretty stable and it's already used in production servers.

[mholt]

This breaking change would just mean that I'd have to go around to _every single directive/plugin_ and change:

httpserver.GetConfig(c).AddMiddleware(func(...) { ...})

to:

httpserver.GetConfig(c).AddMiddleware("directive", func(...) { ...})

which, even if it wasn't a bother to change the setup functions yet again, I'm not sure how I feel about having to pass in the directive name each time (it could easily be mistyped or forged, although I guess I'd just have to trust the developers).

I think I'll let this issue rest for now on the grounds that explicit is better than implicit in this case, although I'm not entirely convinced of that myself. :wink: I'll close this now but mark it as deferred so we may come back to it.

Thanks for raising the issue!

[mholt]

Going forward with v2 (and this answer applies to v1 as well), if you want to take manual control over the redirects (including their headers, etc) then add the redirect to your config explicitly so that you can have control over them.