You've come to this page because you've asked a question similar to the following:
I omitted the trailing dot in the domain name in the http://example.com./ URL because it was a typographical error.
This is the Frequently Given Answer to such questions.
You can find another approach to this answer written by Stuart Cheshire .
No, it wasn't. It was there for a reason. It made the domain name a fully qualified one, and thus unambiguous and not prone to search path spoofing.
Originally, as defined in RFC 1738 (§ 3.1), the "host" portion of a (Common Internet Scheme) URL was always and unequivocally a fully qualified domain name and the conventional mechanism for distinguishing fully-qualified domain names from non-fully-qualified domain names did not apply. Whether it was example.com. or example.com, the host was intended to be the same.
(If you read the URLs in CERN's 1992 list of WWW servers you will see host portions both with and without dots.)
Unfortunately, in practice web browsers have always violated that specification and passed the "host" portion through the name qualification procedures of their DNS Client libraries when mapping the host name to a set of IP addresses.
(For example, those that used the BIND DNS Client library would leave the RES_DNSRCH option set and would not append the final trailing dot if it was missing.)
For example: Posit that the web browser uses the BIND DNS Client library and the search example.net directive is present in that library's resolv.conf configuration file.
In the case that the URL provided by the user is http://example.com/, a web browser would pass example.com to the BIND DNS Client library for looking up its IP address(es). Because the
RES_DNSRCHoption is set and the domain name does not end in a trailing dot, the BIND DNS Client library would take the domain name to not be in fully-qualified form and apply its "search path" mechanism. It would look up example.com.example.net. and, if that domain name happened to exist, would return the IP address(es) corresponding to that domain name instead of the IP address(es) corresponding to example.com.. The web browser would contact the content HTTP server at the former IP address(es) without the user being aware of it.In the case that the URL provided by the user is http://example.com./, a web browser would pass example.com. to the BIND DNS Client library for looking up its IP address(es). Because the domain name ends in a trailing dot, the BIND DNS Client library would take the domain name to be in fully-qualified form and not apply its "search path" mechanism.i It would look up example.com. and, would return the IP address(es) corresponding to that domain name.
The fully-qualified domain name would thus prevent search path spoofing. (See RFC 1535 and RFC 1536 § 6 for more discussion of this.)
(In 2015, after reading this Frequently Given Answer, a commenter on Hacker News reminisced about using this very search path spoofing mechanism to make corporate intranet WWW sites appear, to naïve users who did not understand what the lack of a dot meant, to be under top-level domain names.)
RFC 2396 (§ 3.2.2) reluctantly acknowledges this existing practice, thereby legitimizing the (already existing) notion of (CIS) URLs that employ fully qualified domain names for their "host" portions (http://example.com./) and (CIS) URLs that do not (http://example.com/).
This notion hasn't yet percolated through to all content HTTP server administrators, and we find a few badly configured web sites which don't contain the correct content when accessed using URLs with fully qualified domain names. (Daniel J. Bernstein's web site is one, for example.) However, this is simply an education problem. (Many web sites have no such problem, it should be noted.)
Best practice is thus the following:
If you are a web page author making hyperlinks, use relative hyperlinks where possible. This will make your web pages independent of the domain names used to reach them. When you use absolute hyperlinks, get into the habit of using fully-qualified domain names in your (CIS) URLs where possible. This will eliminate ambiguity and the possibility of search path spoofing.
If you are a web browser user, get into the habit of using fully-qualified domain names in your (CIS) URLs where possible. This will eliminate ambiguity and the possibility of search path spoofing.
If you are a content HTTP server administrator, get into the habit of adding both forms of the domain name when adding a site to your servers (or use content HTTP server softwares that transparently cope with the use of fully-qualified domain names). This will allow web browser users to use (CIS) URLs comprising fully-qualified domain names to access your web sites.
The irony of this change to the semantics of (CIS) URLs, is that it would have been better had the web browsers been fixed to conform with RFC 1738 rather than the standards changed to reflect the web browsers' behaviours. This is not just because doing so has undermined the notion of universality and forced additional work on content HTTP server administrators if they want their web sites to be configured properly, but also because web browsers usually have their own highly visible search path mechanisms anyway (transmuting example into www.example.com, for instance) which they apply to "host" names themselves. So the DNS client libraries' name qualification procedures, operating behind the scenes invisibly to the user, are usually redundant in the first place.