3 ms·

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 importan

by hannob 9y ago

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 9y ago
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/ https://google.com/ and https://google.com./ 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/ https://caddyserver.com/ works, but https://caddyserver.com./ 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 9y ago
  > 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 9y ago
    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.
    - chrismorgan 9y ago
      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 9y ago
      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.
- icebraining 9y ago
  Is there any actual benefit or purpose in supporting both formats?
  - JdeBP 9y ago
    See http://jdebp.eu./FGA/web-fully-qualified-domain-name.html http://jdebp.eu./FGA/web-fully-qualified-domain-name.html .
    - icebraining 9y ago
      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 9y ago
        > 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 9y ago
        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.

by hannob 9y ago

kuschku 9y ago

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/ https://google.com/ and https://google.com./ 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/ https://caddyserver.com/ works, but https://caddyserver.com./ 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 9y ago
> 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 9y ago
  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.
  - chrismorgan 9y ago
    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 9y ago
    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.
icebraining 9y ago
Is there any actual benefit or purpose in supporting both formats?
- JdeBP 9y ago
  See http://jdebp.eu./FGA/web-fully-qualified-domain-name.html http://jdebp.eu./FGA/web-fully-qualified-domain-name.html .
  - icebraining 9y ago
    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 9y ago
      > 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 9y ago
      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.