4 ms·

You make it sound like the Caddy folks completely ignored the issue without providing a reason ("absolutely no reason", "doesn't even consider"). After looking

by piaste 9y ago

You make it sound like the Caddy folks completely ignored the issue without providing a reason ("absolutely no reason", "doesn't even consider"). After looking into it, I find your post misleading and unfair, to say the least. Link to the issue for other users who, like me, were concerned by your post: https://github.com/mholt/caddy/issues/1632 https://github.com/mholt/caddy/issues/1632 According to the author, the issue is that (a) there are two RFCs that contradict each other on this distinction, and (b) most browsers do not treat them as such for the purpose of their same-origin policies. So he thinks it's best not to enable this alternate URL by default since it's trivial to add it as another route if you want. I don't know if he's right or wrong, nevertheless, this clearly isn't a dude that doesn't give a shit.

deleted 9y ago
[deleted]
jimktrains2 9y ago
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.
- piaste 9y ago
  > 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."
  - deleted 9y ago
    [deleted]
  - kuschku 9y ago
    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)
  - jimktrains2 9y ago
    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.

by piaste 9y ago

deleted 9y ago

[deleted]

jimktrains2 9y ago

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.

piaste 9y ago
> 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."
- deleted 9y ago
  [deleted]
- kuschku 9y ago
  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)
- jimktrains2 9y ago
  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.