How about supporting absolute hostnames? Even this site (https://news.ycombinator.com./) supports them just fine, only Caddy doesn’t. Caddy does it so badly that the HSTS preload for caddyserver.com is interpreted by browsers as applying to caddyserver.com. (which is correct), but caddy won't actually serve that spec-compliant website: https://caddyserver.com./ (just throws an SSL error)

The specification explicitly says what you want is the Wrong Thing™. The designers of SNI didn't leave this vague, they spelled it out first in RFC 3546 and most recently in RFC 6066

https://tools.ietf.org/html/rfc6066#section-3

> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. †

So, when your web browser sends the hostname "news.ycombinator.com." that's not an "absolute hostname" that's just an error. Maybe you can demand that web browsers stop doing that, but they'll likely tell you they don't care, and you should stop writing URLs incorrectly.

† The trailing dot rule was in every version, but earliest sources talked about using UTF8 because they pre-date the insight that all this backend (ie not human-facing) stuff can use A-labels which are ASCII and avoid any complicated Unicode problems. This version just says to use ASCII here.

It's not just SNI that's the issue. Caddy also can't handle Host headers with trailing dots, where the spec explicitly states those should be handled.

So while the SNI error is clearly on browsers (and bugs have been already filed), the Host header issue is clearly on caddy (which caddy sees as wontfix)

Honestly, in the 5+ years of Caddy, you're the only person I've ever seen complain about this. And you're relentless about it. You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.

That said, you can just make a site block with that host label and Caddy will handle it just fine. You just need to explicitly ask Caddy for it.

    example.com, example.com. {
        ...
    }

> That said, you can just make a site block with that host label and Caddy will handle it just fine. You just need to explicitly ask Caddy for it.

That's what mholt said as well: It's the site maintainers task to fix it. Yet caddyserver.com still doesn’t support it.

> you're the only person I've ever seen complain about this

I didn’t actually find the bug myself, someone else did first, but it’s something that’s been annoying me for quite a bit.

> You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.

It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.

> Yet caddyserver.com still doesn’t support it.

Right, because Matt (and the large majority of everyone on the internet) doesn't care.

> It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.

Pure FUD. It's such a non-issue. As you've been told many times.

> Pure FUD. It's such a non-issue. As you've been told many times.

If it's such a non-issue, why did matt say he wouldn't accept a PR that'd fix this?

Because it would add unnecessary complexity to the system. It's a waste of time.

This has been a shitty thread to read, tbh. It's clearly not pointless if there are improvements which could be made to make the product more spec-compliant, such as handling terminating dots in Host headers. And I'm saying this as someone who's never used Caddy for anything, ever.

If you want the background story: https://github.com/caddyserver/caddy/issues/1632

This is all from four years ago. And kuschku hasn't taken no for an answer after all this time. It's frustrating and annoying to hear their complaints on every HN thread since.

I agree with you the thread is shitty. I'm just hoping being direct will end the trolling.

Is it "trolling" if one expects a webserver to work like every other webserver, even offering to make the required changes?

If you want to learn why supporting FQDNs is important, you can actually read the issue and PR on the traefik repo where they chose to add support for this:

https://github.com/traefik/traefik/issues/4622 https://github.com/traefik/traefik/pull/4763

They just accepted the issue, and fixed it. Super easy, no 4 years of "no one needs this" "no you're wrong" "the specs are wrong" "you're trolling"

Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.

You make it out to be a simple change, but it's really not. And the arguments for making any changes are not compelling enough to warrant the risks involved. Compliance for the sake of compliance is completely pointless.

> Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.

That’s why I’m comparing it to traefik, which can also automate TLS management, in the exact same way (even using the same libraries for most of the functionality, they’re after all both go webservers).

> And the arguments for making any changes are not compelling enough to warrant the risks involved

Why is it that you think you know better than the maintainers of e.g. traefik? It’s not like this is legacy functionality they kept around just for the sake of it, they added it in 2019 because there’s demand for it, today.

> even using the same libraries for most of the functionality

You're wrong. Caddy uses a superior library that's been more stress-tested at scale in production: https://github.com/caddyserver/certmagic and https://github.com/mholt/acmez - neither of which lego uses. Bugs and limitations in lego caused severe problems for several of our larger customers.

> even using the same libraries for most of the functionality

Actually no, not anymore.

https://github.com/caddyserver/caddy/pull/3621

> because there’s demand for it, today

We've only seen the demand from you. Nobody else. One individual isn't enough demand.

I wonder why that person won't switch to nginx, apache or something else completely, if caddy doesn't work for them.

At this point it's just a game of wasting other people's time.

I’m not using caddy – but I get complaints that websites hosted on caddy servers don’t work with my tools, which follow the specs and require the absolute URL to work just as well as the relative one.

And I can’t remotely telepathically make all caddy users switch to nginx. So as long as a single HTTP server runs a version of caddy with this bug, I’ve got extra work to do, because the caddy people are wasting my time

Hello, ironically it was me who has created that issue some years ago. I saw that http://ai./ works in a browser and wondered why chagemann.de. doesn't. The culprit was caddy, and the caddy maintainer didn't want to fix it (or apparently accept PRs fixing it). Not sure where the trolling is supposed to be at.