Changing default SERVER header

I’m running Caddy v0.11.5, and believe I have identified an anomaly in the behavior of how the “Server” header is handled. Let’s assume, for simplicity’s sake, that I have defined the following header block:

domain.com www.domain.com {
    root /www/website/domain.com

    header / {
        Server "Pumpkin 0.11.5 (Atari 2600)"
    }
}

When I examine the response headers that Caddy produces, I notice the following behavior:

  • If the https site is requested, the proper (“Pumpkin”) Server header is displayed.
  • If the http site is requested, the auto-redirect by Caddy (http->https) exposes the “Caddy” Server header during the 301, rather than using the provided header (i.e., “Pumpkin”).

This is, of course, a bit aberrant behavior. Is there a [config] way of overriding the default Server header when a redirect is involved? Ideally, this should not be necessary… the initial request for the http domain should use the “Server” value found in its domain block, even if it results in an automatic redirect to https.

This also leads me to wonder if the same behavior is observed when the Server header is suppressed entirely (i.e., using “-Server”)… perhaps, on an auto-redirect from http → https, it’s exposed during the redirect response.

1 Like

Hi @LewPayne, welcome to the Caddy community!

This is a function of Automatic HTTPS. When you let it configure the redirect for you, it creates the equivalent of a site definition with no configuration other than the redirect itself.

In order to override the redirect, you can define it manually yourself.

http://domain.com, http://www.domain.com {
  header / Server "Pumpkin 0.11.5 (Atari 2600)"
  redir / https://{host}{uri}
}

Hi Matthew - I was hoping there was a way of simply having Caddy honor the domain configuration block during an auto-redirect. To do what you’re proposing would require the “web maintainer” human (who is non-technical) to now create two sets of domain blocks for each domain. They would have to do this for several hundred domains (I’ve just transitioned the client from Apache to Caddy). Currently, I have them use my import (with common config settings) to make their life simple:

this-site.com www.this-site.com {
    root /www/website/this-site.com
    import /www/webconf/common.inc
}

that-site.com www.that-site.com {
    root /www/website/that-site.com
    import /www/webconf/common.inc
}
... and hundreds more

It seems strange that an auto-redirect doesn’t honor the headers of its matching domain block. Sadly, I guess that’s how it is.

1 Like

You could potentially create a single catch-all redirect, too. But this would also affect sites that you don’t otherwise have configuration for.

http:// {
  header / Server "Pumpkin 0.11.5 (Atari 2600)"
  redir / https://{host}{uri}
}

Somebody hitting up your server on HTTP://:80 would get a redir regardless of the host they requested, but for the vast majority of clients, this will never happen unless DNS actually points at your server.

This also assumes that your Server header content remains consistent between site definitions.

I suppose it’s a quirk of the way configuration and setup is handled. How is Automatic HTTPS meant to know which directives in the site definition are meaningful? It could be coded such that certain directives are always considered applicable to the redirect, but is that always the case? Not everyone will want headers included in HTTPS to also be sent over HTTP for the redirect. Which other directives (or should header be unique in this regard)?

Much better to let the user decide by overriding the redirect themselves rather than making many more assumptions on their behalf in the default setup. You can still get all the functionality you need, it’s just a little more verbose (though probably still not as verbose as other web servers). I expect some crafty sed / awk usage could get you sorted if your Caddyfile is hundreds of sites long.

1 Like

It’s a mix of sites (http, https) on this server… so a blanket redirect would break the non-ssl sites.

“How is Automatic HTTPS meant to know which directives in the site definition are meaningful?” - before the auto-redirect, caddy must already first determine if a domain block exists for that name (else “not served on this interface”). Within the domain block, caddy must already parse the config looking for sub-directives. It appears the auto-redirect could reference this value (Server), if it exists… or even simpler, remove the Server header from all auto-redirects - it’s not really needed!

My first impression was “make them all ssl, since it’s free!” (and I’m guessing that’s what you’re thinking). But over the decades, I’ve learned that marketing often dictates the extent to which technology is used. In this case, the (my) customer charges an upgrade fee for SSL hosting and certificate management. In addition, it creates an opportunity for their clients (customers) to inquire about it - and many of those who do also select to upgrade their 10-year-old website to a modern (in other words - bootstrap template) responsive website… so requiring manual upgrade to ssl becomes a viable business strategy. Granted, those of us who are on the technology side of things don’t see that, but those clients are the ones who pay our bills.

Anyway, I think we can put this to rest. I thought you’d enjoy the inside perspective of client strategy. So, @matt is there any chance of changing Caddy behavior to not issue a Server header during an auto-redirect?

1 Like

This isn’t the case. The http:// site label will only be selected for requests that don’t match a longer site label. If you’ve got that catch-all in your Caddyfile, and you’ve also got http://example.com as a non-SSL site, Caddy will serve http://example.com to clients that request it, not the redirect.

If you want it to look for Server specifically, then it needs to first finish parsing the Caddyfile and then it needs to look inside the header configuration state. This would be far more complicated than simply respecting all header directives in a site definition. Which would still be very complicated, as I expect lifting partial configuration from a site definition will be difficult and we definitely don’t want to lift the entire definition into the auto redirect (what happens if your site definition includes a different redirect…?).

I don’t think Server is less needed for auto redirects than it is for the actual site itself. You might argue that it’s not necessary ever and should be removed entirely, but that’s highly unlikely to happen.

I appreciated the business insight.

2 Likes

@LewPayne Your comments/feedback are particularly useful at this time, as we are looking at making changes to meet the needs of businesses (and our open source users alike). I’ll see what can be done in a future version about the Server header.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.