Closed Bug 635489 Opened 14 years ago Closed 5 years ago

Check whether a hostname is in a known TLD. Add function to nsIEffectiveTLDService

Categories

(Core :: Networking, enhancement, P5)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1621168

People

(Reporter: BenB, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-would-take])

I'd like to check whether a hostname ends in a known TLD. I don't want to do DNS lookups. Possible usecases for that: - More extensive checks on hostnames entered by the user, where apppropriate - Guessing whether a given string is a hostname or freetext URL, e.g. - in the awesomebar - in the URL recognition in plaintext mails We have nsIEffectiveTLDService (the origin of <http://www.publicsuffix.org>), but getBaseDomainFromHost("utter.non.sense") returns "non.sense". That makes it useless for my usecase. I see no other function to check whether the TLD is in the list at all or not. Also, the list is unfortunately directly compiled in, so I can't even load and parse it myself. <http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/dns/nsIEffectiveTLDService.idl>
Whiteboard: [necko-would-take]
Summary: Check whether a hostname is in a known TLD. Add function to nsIEffectiveTLDService. → Check whether a hostname is in a known TLD. Add function to nsIEffectiveTLDService
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5

(In reply to Ben Bucksch (:BenB) from comment #0)

I'd like to check whether a hostname ends in a known TLD. I don't want to do
DNS lookups.
Possible usecases for that:

  • More extensive checks on hostnames entered by the user, where apppropriate
  • Guessing whether a given string is a hostname or freetext URL, e.g.
    • in the awesomebar
    • in the URL recognition in plaintext mails

We have nsIEffectiveTLDService (the origin of
http://www.publicsuffix.org), but getBaseDomainFromHost("utter.non.sense")
returns "non.sense". That makes it useless for my usecase.

I see no other function to check whether the TLD is in the list at all or
not. Also, the list is unfortunately directly compiled in, so I can't even
load and parse it myself.
<http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/dns/
nsIEffectiveTLDService.idl>

Hey!
Is this still active? If yes, then I'd love to work on this
Thanks :)

Flags: needinfo?(honzab.moz)

This doesn't block any bugs and I don't see a use for it. So, no, I don't think we need a patch here.

Ben?

Flags: needinfo?(honzab.moz) → needinfo?(ben.bucksch)

Hi Honza, I need this every time I want to verify a URL or hostname in more depth, without triggering network requests. For example, if you want to verify that an email address is valid, this is highly useful. It is also useful when detecting URLs in plain text, checking hostnames that the user entered in a form, and similar.

This appears in all kinds of cases: <input type="email">, <input type="url">, bug 19313, bug 32442, in the Thunderbird account creation wizard when checking the email address, client-only "single page app" web apps when trying to detect URLs in plain text. This comes up again and again for me.

You cannot imagine how many people misspell their own email address. I can see that in the server logs for my company, e.g. "michael@hotmail".

Blocks: 32442, 19313
Flags: needinfo?(ben.bucksch)

I wonder why this is then 9 years old and a P5.

Anyway, Ben, can you please propose the API how exactly it should it look like?
Thanks.

Flags: needinfo?(ben.bucksch)

It seems that ACString getKnownPublicSuffixFromHost(in AUTF8String aHost); was added in bug 1621168 very recently (last month) for exactly this usecase here. What a coincidence! :-)

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ben.bucksch)
Resolution: --- → DUPLICATE

Sonakshi Saxena, thank you for volunteering for this bug! There are plenty of other useful feature requests still waiting for your engagement. :-)

You need to log in before you can comment on or make changes to this bug.