Caddy – The HTTP/2 Web Server with Automatic HTTPS

Re:Caddy – The HTTP/2 Web Server with Automatic HTTPS by jimktrains2 on Wednesday April 25, 2018 @08:15AM (#16920784)

I don't see two conflicting rfcs. Can you point them out? I saw a link to a Mozilla thread discussing how they should do normalization, but nothing about not supporting the fully qualified format. Cross origin rules don't apply for looking up a virtual host.

Also, the concerns over security the caddy developer make aren't clarified and probably don't exist.

No dot has 2 possible meanins and with dot has one _to the resolving application_. To the server resolving a virtual host there is only one for both.

[ Parent | on HN ]

Re:Caddy – The HTTP/2 Web Server with Automatic HTTPS by piaste on Wednesday April 25, 2018 @06:18PM (#16926815)

> I don't see two conflicting rfcs. Can you point them out?

The quote is:

"RFC 1034 says the two domains are the same, but RFC 3986 says they are not. I can't tell from the http spec whether the two Host values are equivalent or not."

[ Parent | on HN ]

Re:Caddy – The HTTP/2 Web Server with Automatic HTTPS by jimktrains2 on Thursday April 26, 2018 @08:09AM (#16931107)

From rfc 3986:

> The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.

When there is no ambiguity then they mean the same thing.

Anyway, as a sibling comment said, it's not a good rfc to use for this purpose.

[ Parent | on HN ]

Re:Caddy – The HTTP/2 Web Server with Automatic HTTPS by kuschku on Wednesday April 25, 2018 @06:36PM (#16926962)

RFC 3986 is absolutely useless for this task, because no one uses it for this, and it considers things inequal that every browser considers equal.

Besides, it was deprecated by the WHATWG URL spec anyway, which does use the same equality rules as RFC 1034 (after normalization)

[ Parent | on HN ]