250966 - PAC: add support for FQDNs

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[benc]

Should we change the PAC functions to support FQDN's explicitly?

When you have a hostname in a URL like: "www.mozilla.org", most people (and
software) assume it is a FQDN. But, in actuality, it could be a PQDN. For the
purposes of this bug, I will use the following terms:

implied FQDN - looks pretty obviously an FQDN, but is not "." terminated.
explicit FQDN - an FQDN w/ a trailing "."

I've been debating this in my head for some time, and the question boils down to:

strict standards compliance vs. possible performance hit.

In short the problem is from RFC 2396:

The rightmost
   domain label of a fully qualified domain name will never start with a
   digit, thus syntactically distinguishing domain names from IPv4
   addresses, and may be followed by a single "." if it is necessary to
   distinguish between the complete domain name and any local domain.
   To actually be "Uniform" as a resource locator, a URL hostname should
   be a fully qualified domain name.

So, right now, a variety of functions would provide inconsistent results if
tested w/ domains that are explicit FQDNs vs. implied FQDNs.

Should PAC support FQDN's? If so, how should the re-write occur? Should the
incoming host for PAC convert implied FQDNs to explicit FQDNs? This would seem
to have the best performance vs. doing it again and again w/in each function.

As far as risk of regression, I'm not too concerned, because I'm writing a
pretty detailed set of functional tests for each PAC function, that have both
specificaton unit tests as well as parsing unit tests. 

In fact, writing those cases is what brought up this problem.