https://core.trac.wordpress.org/ticket/35248#comment:9のコメント：
最初のリンクによるテキストへの返信（ https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html）：
もともと、RFC 1738（§3.1）で定義されているように、（Common Internet Scheme）URLの「ホスト」部分は常に明確な完全修飾ドメイン名であり、完全修飾ドメイン名と非完全修飾ドメイン名を区別する従来のメカニズムでした。修飾ドメイン名は適用されませんでした。example.comかどうか。またはexample.comの場合、ホストは同じであることが意図されていました。
-私は彼が正しくないと思う、私は「example.com」がrfc 1738に従ってURLでまったく許可されなかったと思う、それは2番目のテキストで引用され、私はそれを引用する：
3.1。一般的なインターネットスキームの構文
// <user>：<password> @ <host>：<port> / <url-path>
ホスト
ネットワークホストの完全修飾ドメイン名
rfc 1738は1994年であり、ホストフィールドは1997年にhttp 1.1でのみ表示されたため、「example.com」はその時点でhttpヘッダーで使用できませんでした（ウィキペディアで確認できます）。
そのため、実際には、URLにはfqdnのみが許可されていました。私は、このような方法で「相対ドメイン」機能を役に立たないようにしたので、これはrfc 1738のエラーだったと思います。ブラウザやサーバーがサポートしていれば、理論的には、ローカルスクリプトサイトの「a」タグhrefまたは相対ドメインを使用する大企業内の静的htmlドキュメントで使用できます。しかし、rfc 1738がそれらを許可しなかったとしても、人々はそれに従わなかった：彼らは相対的な形式で、すなわち後続ドットなしでトップレベルドメインを使用し続けたので、とにかくrfc 1738によるこの禁止は大きな実用的な問題ではなく、人々は代替手段を持っていた相対ドメイン：「localhost」のようなローカルトップレベルドメインを作成しました（そして、ドットを使用せずに使用します）。
彼は言う：
残念ながら、実際にはWebブラウザーは常にその仕様に違反しており、ホスト名をIPアドレスのセットにマッピングするときに、DNSクライアントライブラリの名前修飾手順で「ホスト」部分を渡しました。（たとえば、BIND DNSクライアントライブラリを使用したものは、RES_DNSRCHオプションを設定したままにし、最後のドットが欠落している場合は追加しません。）
-末尾のドットのないホストはエラーとして破棄されるだけで、絶対ドメイン（fqdn）のみがdnsに渡されるべきだと彼は言ったと思います。「localhost」などのカスタムローカルトップレベルドメインを使用しているため、ブラウザはすべてのドメインをDNSに渡したと思われます。とにかく、1998年に公開されたrfc 2396で、URLの末尾にドットなしのトップレベルドメインの使用が許可されました。
著者（Jonathan de Boyne Pollard）は、rfc 2396を引用し、確立された人間の行動、つまり事実上の標準に従って変化したことについて後悔し、ブラウザがrfc 1738に従った方が良いと言い、すべての人々にfqdnのみを使用することを推奨rfc 1738が命じたすべての場所。
-しかし、人々がrfc 1738に従うとどうなりますか？「のようなURLhttp://example.com/test.html "および"http：//localhost/test.html「すべてを次のように書き換える必要がありました」http://example.com./test.html "and"http://localhost./test.html「。ブラウザは、ドットのないホストをエラーとしてマークするか、クリックしたときにホストを完全/絶対形式にリダイレクトする必要があります。「localhost」などのローカルトップレベルドメインを設定したすべてのユーザーは、リクエストのみを受け入れるようにサーバーを設定する必要があります"localhost。"などのドメインの場合、または[localhost内のすべてのURL]を[localhost]に受け入れてリダイレクトします。[localhost]のようなテキストは、ブラウザのアドレスバーに入力する場合にのみ役立ちますが、ブラウザーは入力時にドメインを検索するため、そのようなリンクは機能しないか、すべてをクリックすることにつながるため、HTMLソースでのドメインの使用は無用になります。 「localhost」とリンクすると、ユーザーは「localhost」に移動します。（リンクをクリックするたびに追加のリダイレクトが行われるだけです。そのため、rfc 1738は計画された「相対ドメイン」機能をまったく役に立たないものにします。その機能を使用し、ローカルサイトで相対ドメインを使用した場合、相対ドメインを含むURLはブラウザによって絶対形式にリダイレクトされなかったため、サイトは正常に機能し、rfc 1736に従っても、fqdnのみを受け入れるようにサーバーを構成し、そのようなURLをすべて書き換える必要がありますfqdn、またはそのようなURLのクリックごとに余分なリダイレクトを使用する。その会社が、アドレスバーとhtmlソースに「team101.microsoft.com。」ではなく「team101」のような短いドメインを持つことを好む場合、使用を開始する必要があります。 「team101」のようなカスタム内部トップレベルドメイン、つまり「「localhost。」のようなサブドメインではなく、「team101.microsoft.com。」（rfc 1738に従うことを決定する前の「team101」として使用できます）。
-
そして、rfc 1738で非常に強力にサポートされていた末尾のドットは、実際には末尾のドットのない標準の後にのみ現れることがわかりました！1987年にrfc 1034で登場し、2番目のリンクで引用されています。
完全なドメイン名はルートラベルで終わるため、これは
ドットで終わる印刷フォーム。このプロパティを使用して、以下を区別します。
-完全なドメイン名を表す文字列
（しばしば「絶対」と呼ばれます）。たとえば、「poneria.ISI.EDU」。
-の開始ラベルを表す文字列
不完全なドメイン名
ローカルドメインの知識を使用したローカルソフトウェア（多くの場合、
「相対」と呼ばれます）。たとえば、「ポネリア」
ISI.EDUドメイン。
rfc 1034（1987年）は、使用されたすべてのドメインを宣言したばかりで、末尾のドットがなく、すべて相対ドメインになると宣言されたようです！しかし、彼らはまだ以前と同じように働いていたので、おそらくそれを知っている人はほとんどいなかったでしょう。有名な実際のexample.comは、「localhost。」などのローカルドメインを作成する権限が与えられていなくても、サブドメイン管理者になりすまされる可能性があります。そのため、rfc 1034もあまりうまく設計されていません。その作者は、{広く知られていないため、セキュリティ侵害を引き起こす}かもしれないとは思わなかったようです。
おそらくrfc 1738（1994）は最終的に、絶対ドメインと相対ドメインの区別のアイデアを幅広い視聴者にもたらし、6年後にそのセキュリティ侵害を修正しようとしましたが、{ 、{しかしそれらはおそらく広く使われていなかったと思う、おそらくいくつかの大企業でのみ}}。それで、もし従うなら、rfc 1737の結果の[左]は何でしょうか？-1）1987年に宣言された相対ドメインは最終的に役に立たなくなるため、絶対ドメインを示すように設計された末尾のドットも、最終的に役に立たなくなり、「法的に」冗長になります。（しかし、多年後に一般の人々が相対ドメインの可能性について知るようになると、URLの相対ドメインを後で許可することを計画したかもしれません）。2）およびrfc 1737、それに従った場合、セキュリティ違反も修正されます。-しかし、rfc 1034でさえ、大衆に達するとセキュリティ侵害を引き起こさず、相対ドメインを使用することは安全ではないと広く理解されていました！-それで、それを修正する主なレシピは幅広い聴衆に届きました、そしてもう一つのrfcを公開することはそれをする多くの方法の1つにすぎませんでした。
私は今、おそらく相対的なドメイン機能はあまりにも限られた使用のためだったので、RFC 1034（1987年）後に広く知られていなかったと思います：一部の大企業またはプロバイダーのローカルネットワークでのみ、それは実用的価値のない機能でした、ローカルネットワークは既にローカルドメインを作成できたため、その機能はそれだけのためのものであり、実際にはrfcの役に立たないテキストであり、誰もが追加の利益なしに知って使用する必要があります。しかし、人々はrfcを広く無視することで小さなセキュリティ侵害を引き起こしましたが、ブラウザはそれを聞き始めました。
昨日、相対ドメイン機能をチェックしましたが、機能します。（それは大丈夫です、なぜならrfc 2396（1998年）はrfc 1034（1987年）が拒否された後に再び許可し、後でrfc 3986（2005年）はまだそれらを許可しているからです）。Windows 10にDNSサフィックスを追加しました-コントロールパネル-...-ネットワークデバイスプロパティ-ipv4プロパティ-追加-DNSタブ。「google.com」を追加してから「http：// mail / "firefoxでは、Googleのサーバーを開きましたが、http" host "ヘッダーの" mail "だけで動作するように構成されていなかったため、" 404 "ページのようなものが表示されました。
-
2番目のリンクによるテキストへの返信（ http://www.dns-sd.org/trailingdotsindomainnames.html）：
彼はまた、rfc 1738のルールを引用し、次のように述べています。
残念ながら、Webブラウザークライアントを実装する人々は、これが何を意味するのか理解していないようでした。Webサイトにアクセスするとき、ほとんどのWebブラウザーが「ホスト：」フィールドに入力する値は、DNSユーザーの検索リストを適用してからの完全修飾名を構成した後、コンピューターが実際に使用したものではなく、ユーザーが入力したものです部分的な名前。たとえば、ユーザーがホスト「www.example.com」を参照する3つの異なる方法を次に示します。... Webホストに「Host：」パラメーターを送信するとき、Webブラウザークライアントはユーザーが入力した内容（「www.example.com。」、「www.example.com」、または「www」）を代わりに入力しますクライアントが実際にDNSで検索した結果（3つすべてのケースで「www.example.com」）。...
-これはあまり正しくありません（正しい）。これは、rfc 1738がこの点で非常に厳格であり、ブラウザのアドレスバーにある場合でも、すべてのURLで相対ドメインを許可しないためです。サイトへの参照は、人々が紙に書いたとしても、ユーザーがURLを使用していると考えた場合、rfc 1738によってその3つの方法でそのサイトを参照することは許可されませんでした！
このテキストの著者（Stuart Cheshire）はrfc 2396について知らなかったため、このテキストは古くなっています。
-
そして最近の状況はどうですか？rfc 3986（https://tools.ietf.org/html/rfc3986#page-21）は、ドットなしで絶対ドメインを参照することを許可します：「DNSの完全修飾ドメイン名の右端のドメインラベルの後には1つ続くことがあります」。 「」および「完全なドメイン名と一部のローカルドメインを区別する必要がある場合」に使用する必要があります。事実上の標準のため、それはほとんど必要ではないと思うので、ワードプレスは事実上の標準を受け入れ、末尾のドットを持つアドレスからそれなしのアドレスにリダイレクトできます。