[wp-trac] [WordPress Trac] #35248: WordPress should remove domain trailing dot (as/like it removes "www.")

[WordPress Trac]

#35248: WordPress should remove domain trailing dot (as/like it removes "www.")
-------------------------+------------------------------
 Reporter:  qdinar       |       Owner:
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Canonical    |     Version:  4.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by qdinar):

 my reply to the text by the first link (
 https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA
 /web-fully-qualified-domain-name.html ):

 >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.

 -- i think he is not right, i think "example.com" was not allowed at all
 in urls according to rfc 1738, it is cited in the second text, and i cite
 it:

 {{{
 3.1. Common Internet Scheme Syntax
         //<user>:<password>@<host>:<port>/<url-path>
     host
         The fully qualified domain name of a network host
 }}}

 and "example.com" could not be used in http headers at that time, because
 rfc 1738 is of 1994 and host field appeared only with http 1.1 in 1997
 (you can check in wikipedia).

 so, indeed, only fqdn was left allowed in urls. i think, this was a error
 in rfc 1738, because in such way it made (tried to make) the "relative
 domains" feature useless. if it did not disallow it, they theoretically
 could be used in "a" tag hrefs in local scripted sites or static html
 documentation inside big companies that used relative domains, if browsers
 and servers supported it. but even if rfc 1738 disallowed them, people did
 not obey it: they continued to use top level domains in relative form ie
 without trailing dot, so this disallowing by rfc 1738 was not a big
 practical problem anyway, and people had and used an alternative to
 relative domains: they just made local top-level domains like "localhost"
 (and used and use them also without trailing dot).

 then he says:
 >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.)
 -- i think he meaned that hosts without trailing dot should be just thrown
 off as error, and only absolute domains (fqdn) should be passed to dns. i
 think probably browsers did pass all domains to dns because people used
 their custom local top level domains like "localhost". and anyway, later
 in rfc 2396 published in 1998, the usage of top level domains in urls
 without trailing dots was allowed.

 then the author (Jonathan de Boyne Pollard) cites rfc 2396 and regrets
 about it changed according to the established human behaviour ie de facto
 standarts, says that better would be if browsers obeyed rfc 1738, and
 recommends to all people to use only fqdn, in all places, as it was
 commanded by rfc 1738.

 -- but what would happen if people obeyed rfc 1738? urls like
 "http://example.com/test.html" and "http://localhost/test.html" all had to
 be rewritten as "http://example.com./test.html" and
 "http://localhost./test.html". browser would have to either mark hosts
 without dots as error, or redirect on clicking them to full/absolute form
 of them. all people who configured local top-level domains like
 "localhost" would have to configure their servers to accept only requests
 for domains like "localhost." , or accept and redirect [all urls inside]
 "localhost" to [corresponding urls in] "localhost.". text like "localhost"
 would stay useful only when typing it in browser address bar, but that
 would be only very useless usage, and the relative domain feature is not
 neeeded for that, because browsers search for domains on typing. usage
 them in html source would become useless because it would lead to that
 links would not work, or clicking all links with "localhost" would move
 user to "localhost." and it would be just extra redirect on every click.
 so, rfc 1738 would make the planned "relative domain" feature entirely
 useless. if some company used that feature, and used their relative
 domains in their local sites, and their urls with relative domains were
 not redirected to absolute form by browsers, so their sites worked
 normally, if they also obeyed rfc 1736, they would configure their servers
 to accept only fqdn, and they would have to either rewrite all their such
 urls with fqdn, or work with extra redirect on every click on such urls.
 if that companies liked having short domain like "team101" instead of
 "team101.microsoft.com." in their address bars and html sources, they
 would have to start use their custom internal top-level domains like
 "team101." ie like "localhost." instead of subdomains like
 "team101.microsoft.com." (which could be used as just "team101" before
 they decided to obey rfc 1738).

 ---

 and i have found out that the trailing dot, which was so strongly
 supported by rfc 1738, really appeared only after the standart without
 trailing dots! it appeared with rfc 1034 in 1987, it is cited in the
 second link, and i cite it:


 {{{
 Since a complete domain name ends with the root label, this leads to a
 printed form which ends in a dot.  We use this property to distinguish
 between:
 - a character string which represents a complete domain name
  (often called "absolute").  For example, "poneria.ISI.EDU."
 - a character string that represents the starting labels of a
  domain name which is incomplete, and should be completed by
  local software using knowledge of the local domain (often
  called "relative").  For example, "poneria" used in the
  ISI.EDU domain.
 }}}

 rfc 1034 (of 1987) just declared all domains which were used, seems they
 all were without trailing dots, declared them all as becoming relative
 domains! but they still worked as before, so probably few people knew out
 about that, and continued to think that they are unambiguously requesting
 a unique real "example.com" site when they use "example.com" without
 trailing dot. so that has become an additional security breach in some
 cases: famous real example.com could be spoofed by a subdomain
 administrator even if he was not given rights to make any local domain
 like "localhost.". so, rfc 1034 also was not designed very well: seems its
 authors did not expect that maybe it will be {not widely known, so
 creating security breach}!

 probably rfc 1738 (1994) tried finally to bring the idea of distinction
 between absolute and relative domains to wide audience and also fix that
 security breach after 6 years, {but by fixing the security breach by
 disallowing relative domains in urls it made relative domains useless,
 {but i think they probably was not used widely, probably only in some big
 companies}}. so, what would be [left] in result of rfc 1737, if it would
 be obeyed? - 1) relative domains declared in 1987 would become finally
 useless, so, trailing dot, designed to show absolute domain, also would
 become finally useless and redundant "legally" ie as defined by the rfcs!
 (but maybe they planned later re-allow relative domains in urls after many
 years, when wide audience (general public) start to know about the
 possibility of relative domains). 2) and rfc 1737, if it was obeyed, would
 also fix the security breach. - but even rfc 1034 would not create the
 security breach if it reached masses and it was widely understood that
 using relative domain is not safe! - so, main recipe to fix it was
 reaching the wide audience, and publishing one more rfc was just one of
 many ways to do it.

 i think now that probably the relative domain feature has not become
 widely known after rfc 1034 (of 1987) because it was of too limited use:
 only in some big companies or providers' local networks, and it was a
 feature with no practical value, because local networks could already make
 any local domain, so that feature was just for itself, it was in fact just
 a useless text in rfc that anybody should know and use without having any
 additional benefit! but people created the little security breach by
 widely ignoring the rfc, while browsers started to obey it.

 i checked the relative domains feature yesterday, it works. (it is ok,
 because rfc 2396 (of 1998) re-allowed it after rfc 1034 (of 1987) denied,
 and later rfc 3986 (of 2005) still allows them). i added dns suffix in
 windows 10 - control panel - ... - network device properties - ipv4
 properties - additional - dns tab. when i added "google.com" then opened
 "http://mail/" in firefox, it opened google's server, but it was not
 configured to work with just "mail" in the http "host" header, so i got
 something like "404" page.

 ---

 my reply to the text by the second link ( http://www.dns-
 sd.org/trailingdotsindomainnames.html ):

 he also cites the rule in rfc 1738 and says:

 >Unfortunately, the people implementing web browser clients appeared not
 to understand what this meant. When you access a web site, the value most
 web browsers put in the "Host:" field is what the user typed, not what the
 computer actually ended up using, after applying the DNS user's searchlist
 to constuct a fully-qualified name from the partial name. For example,
 here are three different ways the user may refer to the host
 "www.example.com." ... When sending the "Host:" parameter to the web
 server, the web browser client puts in what the user typed
 ("www.example.com.", "www.example.com", or "www") instead of what the
 client ended up actually looking up in DNS ("www.example.com." in all
 three cases). ...

 -- this is not very true(correct), because rfc 1738 was very strict, and
 it disallowed relative domains in all urls, even if it is in browser's
 address bar, and url itself is the way of making any references to sites,
 even if people write it on paper, so users are not allowed refer to a site
 in 3 ways!

 and seems the author of this text does not know about rfc 2396, so this
 text is outdated.

 ---

 and what is the situation nowadays? rfc 3986 (
 https://tools.ietf.org/html/rfc3986#page-21 ) allows referring to absolute
 domain without trailing dot: it says "  The rightmost domain label of a
 fully qualified domain name in DNS may be followed by a single "."  " and
 that it should be used if it is "necessary to distinguish between the
 complete domain name and some local domain". i think that due to de facto
 standarts it is almost never necessary, so wordpress can accept the de
 facto standart and redirect from address with trailing slash to the
 address without it.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35248#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform