-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
the real world isn't RFC compliant #14
Comments
Thanks. This sounds like a great new feature add. Do you have an authority for this other than manual testing?
I’m wondering what other chars we’re missing. does W3 or WHATWG say anything? If not, I can fish through Chromium / Firefox source and compare their hostname code path.
…On Fri, Sep 4, 2020 at 11:27, wakemaster39 ***@***.***> wrote:
Unfortunately the real world does not listen to RFCs, _ can be in hostname parameters, DNS respects it, chrome respects it but we fail here.
We should introduce a strict mode and a loose mode for trying to allow for better real world compatibility where required.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [view it on GitHub](#14), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHY5FANH7YMYNQE64OVS6QDSEEBM7ANCNFSM4QYUOGBQ).
|
no I don't have any authority, my knowledge is mostly statck overflow, random microsoft docs, bind9 configuration and a bit surrounding the other DNS record specs which rely on I haven't found in my search any other character besides |
okay, i’ll look at chromium source and see what I find. I’m hoping there’s a weird 27th letter to the alphabet.
…On Fri, Sep 4, 2020 at 21:15, wakemaster39 ***@***.***> wrote:
no I don't have any authority, my knowledge is mostly static overflow, random microsoft docs, bind9 configuration and a bit surrounding the other DNS record specs which rely on _ pretty heavily. But this change does not support those at all.
I haven't found in my search any other character besides _ and punycode handling for UTF characters.
—
You are receiving this because you commented.
Reply to this email directly, [view it on GitHub](#14 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHY5FAPVCBOXTUBM3SLPU3DSEGGKBANCNFSM4QYUOGBQ).
|
look at this madness https://tools.ietf.org/html/rfc1123
|
There is a typo in that table, it had me concerned there for a minute. Must is 63 not 635 characters like is already supported. Unfortunately it doesn't talk any more about |
Yeah, I agree that 635 must be a typo. Originally this repo had the goal of validating domain names for certificate authorities.
Following some of the debate on Stack Overflow, hostnames seem to be a subset of domain names following the rules we know already in this repo. A record's name in a DNS server can contain an underscore, such as Like you said, what you're replicating here isn't for hostnames, and it isn't for web certificate authorities. So what is it? Idk? Something that Chromium does? Here's Chromium source: chromium - net/dns/dns_util.cc We do gain something from this that diverges from our current regex: this allows the last octet in a label to be a hyphen. And looking back at RFC 1035 s. 2.3.1 Preferred Name that's a bug which I've filed as #16. (oops) I haven't quite traced out the full code path yet, but it seems like labels with leading dashes are accepted by both Chrome and Firefox. Anyway, the top of the chromium source notes: And that would seem to point to Daniel J. Berenstein and the djbdns server and dns utils. This is a sad place to end the egg hunt, because I don't see a good reason why underscores are included other than tradition. I don't mind accepting this feature, but perhaps should be named after |
I agree this is a really shitty answer, as I have also not been able to find a reason for underscores other than chrome/firefox/safari said they accept them. I am happy to change the name, I went with I would vote for |
Unfortunately the real world does not listen to RFCs,
_
can be in hostname parameters, DNS respects it, chrome respects it but we fail here.We should introduce a
strict
mode and aloose
mode for trying to allow for better real world compatibility where required.The text was updated successfully, but these errors were encountered: