[hannob]

Caddy is written in a memsafe language.

(I don't use caddy, but I always saw the "HTTPS by default" thing more as a nice thing to have, but not hugely important given that you can have the same with external scripts in apache or nginx. But being memsafe is the real distinguisher and one that certainly isn't reachable with a pull req in apache or nginx.)

[kuschku]

Caddy doesn’t even adhere to the URL RFCs.

The URL RFCs specifically say that a DNS name in a URL can be written relatively, or absolutely with the root zone.

These are valid URLs: https://google.com/ and https://google.com./ As you notice, both work fine. Same with every major site, and every major webserver.

Now, you’ll notice that https://caddyserver.com/ works, but https://caddyserver.com./ doesn’t. Caddy, the server, doesn’t support it, but you have to enter every domain twice manually. And caddy, the website, doesn’t support it either.

This was closed as a WONTFIX, despite every implementation of a webserver except for traefik and caddy doing it the same way.

[chrismorgan]

> Same with every major site, and every major webserver.

I last tried this a few years back (probably around 2011). I found that a substantial fraction of major sites did not support it, and a substantial fraction of those that seemed to support it produced web pages that were at least partially broken.

[kuschku]

I tried it in 2016 again, and under the alexa top million sites, I found basically all supported it, even if just with a redirect.

Mostly because nowadays every CDN, nginx, Apache2, IIS and HAProxy all support it by default.

[icebraining]

IIS might support it, but Microsoft doesn't (universally): social.technet.microsoft.com, live.com, bing.com, office.com, skype.com all fail to properly load or redirect. As does instagram.com and linkedin.com.

[chrismorgan]

It sounds like the situation has improved (if you consider it an improvement!) since then.

But did all of them function correctly? Assertions about the host are very common. Many things operate by domain whitelists, and so things like font loaders and analytics will commonly not work. Cross-origin resource loading will often break, if `*` is not used.

(Most of the things that I expect to break are unimportant, but there will still be a non-trivial number of important breakages.)

[icebraining]

Is there any actual benefit or purpose in supporting both formats?

[JdeBP]

See http://jdebp.eu./FGA/web-fully-qualified-domain-name.html .

[icebraining]

So, it's to be able to indicate that we wrote a FQDN, otherwise the DNS client, if it has a local search path, will check if it's a relative domain first.

I have to admit it's technically a benefit, but if you have a search path that resolves FQDNs as relative domains, isn't half of your software broken anyway? I can't say I've ever seen a FQDN with a dot at the end on any hardcoded or default value.

[kuschku]

> but if you have a search path that resolves FQDNs as relative domains, isn't half of your software broken anyway

That’s correct, but it shouldn’t be that way.

I should be able to have google.com resolve to google.com.local.kuschku.de in my resolver, without issue, and the actual website should use google.com.

The fact that we don’t do that today breaks many parts of the original DNS and URL RFCs.

[fulafel]

DNS software has absolute domain names in config files. In BIND zone files you have entries like "IN NS ns1.example.com." specifying the nameserver for the domain.

I bet some software implicitly uses absolute domains. URLs are just specified not to work like that.