httpcaddyfile: Add auto_https global option

[francislavoie]

Fixes #3219

Adds a new global option to the Caddyfile to configure Automatic HTTPS:

{
	auto_https [off|disable_redirects]
}

---

Disabling redirects from Caddyfile:

{
	auto_https disable_redirects
}

localhost

JSON:

{
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"match": [
								{
									"host": [
										"localhost"
									]
								}
							],
							"terminal": true
						}
					],
					"automatic_https": {
						"disable_redirects": true
					}
				}
			}
		}
	}
}

---

Disabling Auto HTTPS completely from Caddyfile:

{
	auto_https off
}

localhost

JSON:

{
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"match": [
								{
									"host": [
										"localhost"
									]
								}
							],
							"terminal": true
						}
					],
					"tls_connection_policies": [
						{}
					],
					"automatic_https": {
						"disable": true
					}
				}
			}
		}
	}
}

[mholt]

@francislavoie Thanks for working on this!!

The extra TLS conn policy is intentional as you discovered, but in this case I think it's because we don't look inside to see that the only connection policy is empty except for the ServerName filter. It's not really something I want to change right now but if we find out that it's safe to take out the extra policy, we can do so. (The extra one in this case might actually be the first policy, not the empty second one.) I might be wrong, but I think that logic of adding the empty one at the end is mostly for cases where the non-empty one actually sets something about the TLS connection that is different from the default.

Anyway, I'll look at this more after 2.0, but one thing I'm not sure about already is whether HTTP redirects belong being configured in the tls directive.

In general, I suppose people would rather disable them because they don't have permission to bind to the HTTP port, or don't want an extra socket to be bound in the first place. For that case, a global option seems to be a better fit. I haven't yet seen a use case where people want to disable it per-site in a way where they can't use another server block (i.e. http://example.com) for that to override the implicit redirects.

[francislavoie]

IMO tls and automatic_https feel like inextricably linked concepts, I don't think it's much of a stretch to put it there.

I do concede that it's not ideal that to set disable_redirects it adds a "tls_connection_policies" item to the JSON that otherwise wouldn't be there.

I don't love the global option idea, it feels incongruent to the way site blocks work.

[mholt]

The tls directive should deal only with the transport layer, not the HTTP application. We cannot break that abstraction cleanly.

The HTTP->HTTPS redirects don't occur within the user's site block anyways, because they happen on a port different than what the user has configured in their Caddyfile. Global options were made for things that can't be cleanly configure inside site blocks. So a global option is a better solution because A) it's more useful for solving @sqs 's original request, and B) it changes something that doesn't occur in any of the site blocks in the Caddyfile.

[mholt]

Don't put a lot of work into overhauling this PR yet though -- it needs more careful thought and consideration I think.

[mholt]

As I fiddle with this more, I'm thinking this should be a global option on our first pass, at least, since the point of disabling auto-redirects is almost always to avoid even binding to the extra socket. With this implementation, you'd have to add this to all your server blocks.

I think I'm envisioning this instead:

{
    auto_https disable_redirects
    auto_https off
}

at least, for a first pass I think this would be useful. WDYT?

[francislavoie]

Sounds okay to me.

I think there would still be value in running the routine to collect the domains for redirects even if disable_redirects is set, so that it can be populated to be used in a manner like in #3246.

Does that make sense to you?

[mholt]

I don't know yet - but that's totally separate, so I don't want to be concerned with it in this issue/PR. For now, a way to disable the redirects is enough.

[francislavoie]

That's what I mean though, with disable_redirects it can just do the work up to the point where it would it to the config, then it just doesn't add it.

Anyways, okay I'll rework this PR soon.

[francislavoie]

@mholt okay this should do it 👍

[mholt]

Awesome, this is looking much better! Just one suggestion.

[mholt]

Consider using switch here, and be sure to reject unrecognized values.

[francislavoie]

The Caddyfile parse step already rejects other values, but sure, doublechecking aint bad.

[mholt]

Oh, I hadn't noticed that. I guess that should be fine then...

[averri]

I have tried this Caddyfile:

{
  auto_https disable_redirects
}


:443 {
  tls /etc/caddy/fullchain.pem /etc/caddy/privkey.pem
}

# Other config

... and the following error occur:

{"level":"info","ts":1590408669.3928888,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
run: adapting config using caddyfile: unrecognized parameter name: auto_https

What is the correct configuration to disable the redirect from port 80?

[francislavoie]

@averri this was only recently merged. v2.0 doesn't have this feature. It'll come in v2.1

For now you can compile from source or use the latest build from CI.

[davidpanic]

Is there an option to disable it per subdomain yet? One of my clients does not support https, but on the same subdomain most others do. Therefore I would need to disable redirects for all my domains and subdomains and manually add them back for each one except that one subdomain which is kind of annoying.

[francislavoie]

@psrcek just set up an http://sub.example.com site block for that one subdomain to override the redirect.

Next time, please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests. Don't forget to fill out the thread template so we can help you!

[solariz]

@averri this was only recently merged. v2.0 doesn't have this feature. It'll come in v2.1

Is there any news? v2.2.1 still "unrecognized directive"

[francislavoie]

@solariz Please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests. Don't forget to fill out the thread template so we can help you!