-
Notifications
You must be signed in to change notification settings - Fork 4
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
slds aren't handled properly by the 'domain' regexp #5
Comments
Here's an updated list of "public suffixes": http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 |
Quite a big list. This is going to add considerable weight. Worth it though. |
I think there are uses cases for both. Ideally I think we should expose a light and a full package. Weight doesn't really matter in node the same way as it does in the browser, so both are valuable imo. |
Yeah, in Node it might be useful with a whitelist-based TLD validation anyway, for instance to make sure that a domain could be hosted by a company. In that case the user should probably have influence on the content of the whitelist though, which wouldn't be compatible with how it's done now. Can you think of any specific use cases where the TLD whitelist can still be purely controlled within the package as it has been done up to now, and is shown in this issue? New TLDs are added constantly nowadays, so with a whitelist we probably need to release new versions every time a new one is added (whenever https://publicsuffix.org/list/effective_tld_names.dat doesn't give a 304, I guess). In the browser the use case for whitelist-based validation is very limited as I see it, especially due to the rate at which new TLDs are added and the use case of being able to send e-mails to TLDs which hit production hours ago. I think we could offer a generic way of doing plugins in one-validation, and adding the whitelist-based validation based on this issue + the new gTLDs etc. that way. It could of course also be a separate file in the same package, so the users can choose which file to implement. The main issue is prioritisation. Would it be acceptable if a new version based on #6 is released for now (so without whitelist approach) and that re-implementing the whitelist is postponed until there is time or a strong use case for it? |
I'm not aware of any dependents other than purify and npmjs.org doesn't show a lot of downloads. I think it's ok to pull out the tld whitelist. Just be sure to release a new major version when you do. |
Cool thanks, will make sure to do that. |
The text was updated successfully, but these errors were encountered: