我读过这个问题,URL如何有一个点。最后,例如www.bla.de。?并意识到FQDN应该包含DNS树的根标签的结尾.

example.com.而不是example.com

但是,此博客文章中指出了一些问题:


如果您不认为用户可能会不小心输入
末尾带有圆点的域名,或者点击从
收到的链接一些“祝福”,并在您的域名上加上
末尾的点,结果可能会导致意外的后果:

1)如果网站使用HTTPS,则导航至域名末尾带有
的点,浏览器将在不受信任的
连接上显示警告。

2)身份验证可能会被破坏,因为通常会设置cookie
域名的末尾没有点。在这种情况下,用户会很
为什么他无法登录。值得注意的是,如果您为域名后面设置一个
cookie,并在其末尾加一个点,则该cookie将不会
传递到域名的末尾不带点,反之亦然。

3)页面上的JavaScript可能损坏。

4 )网站页面的缓存可能存在问题(例如,对于
,如果
域名的末尾带有点号,则认为该域名无效,则https://www.cloudflare.com/不会清除页面缓存) 。

5)如果在Web服务器配置中,您依赖
特定域名(Nginx中的$ http_host,Apache中的%{HTTP_HOST})
,但不带点最后,您可能会遇到各种意外的情况
:意外的重定向,基本授权问题等。

6)如果未将Web服务器配置为接受
带有尾号的域名,任何接受ntal键入a
带有尾随点的域名将显示类似错误请求
-无效的主机名。

7)搜索引擎可能会发现您的资源具有重复的内容,如果有人不小心或故意将
链接发布到您的网页,并且在域名的末尾加了点。


我也意识到http://webmasters.stackexchange.com./确实具有400 Bad Request的功能。但是由于正确的域名应该在末尾包含一个.,我们是否应该对主机名发出400错误或301重定向而没有尾随点?以连贯一致的方式处理此问题的正确方法是什么?

评论

这个点有一个严重的误解,但是我写答案已经太久了,我可能会说错话。可以说圆点代表域名的根或父级。这里的根是“网站管理员”,根是“点”,因此“点”将不在URI的末尾,在这种情况下,我认为它根本不属于URI。正如我说的,我已经忘记了太多的确切操作,我会将其留给其他人。

我只想留下笔记;使您的域名与兼容。 -就我个人而言,我总是在最后加一个点,不知道为什么,而且我注意到很多网站与此都不兼容。

的。域名末尾的[点]始终是透明的,并不打算由用户使用。它是TLD的根(TLD是域).com。我个人不会担心在我的朋友William的URL末尾加点的奇怪的蝶形螺母,这确实令人印象深刻。 ;-)

@closetnoc好吧,我应该承认;)这只是一个怪异的习惯。您不应因为用户行为而优化您的网站使其兼容,而是由于技术方面的原因。
@ WilliamD.Edwards至少它并不像用脚趾咬牙一样奇怪...不是我这样做了...

#1 楼

要部分回答您的问题,可以将其添加到htaccess规范转发器规则中。从基本的HTTP角度来看,它会在URI之前查找一个时间段,并将其应用于您使用的任何反复制转发机制中。这是一个包含公用“附加域”子实用程序路由的示例:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/" [R=301,L]


这样做是将以下所有内容转发到规范的HTTP www域: br />

domain.hostdomain.com
domain.hostdomain.com。
www.domain.hostdomain.com
www.domain.hostdomain.com。
domain.com
domain.com。
www.domain.com。

全部转发至:


http: //www.domain.com

不过有一个警告-如原始博客报价所述,SSL将无法正确转发,并且会在大多数服务器中发出浏览器警告或400错误的请求错误实例(尤其是HSTS)。这是因为它在TLD后的用例中看到了“主机” SSL。我不确定是否有解决主机SSL警告的解决方法,因为它在htaccess和其他东西之前出现。

评论


除了:而不是从每个可能的域重定向到规范的example.com。可能更容易地说:如果不是example.com,则重定向到example.com。 (?)

–怀特先生
16 Dec 27'2:38



#2 楼

我喜欢将尾随点视为互联网的“真正”根源,并且它位于美国弗吉尼亚州。如果省略点,则总是隐含一些根。对于普通用户,这是相同的根源,这就是我今天要讨论的情况。

以我不正当的方式,我实际上发现尾随点很方便。如果我要检查别人的网站,并且想重新开始,没有缓存,没有cookie等,而且我懒得将其冲洗掉,则可以使用其他浏览器,也可以添加点。如果该网站没有重定向我,那么我将获得该网站所有页面和其他资源的全部未缓存URL。

作为网站管理员,我希望所有查看该页面的人和机器人都是使用相同的URL查看它,因此使用相同的主机名进行查看。如果主机名不是我希望他们使用的主机名,我将立即进行301重定向,以便他们在浏览器中看到正确的URL。对于基于PHP的站点,我使用PHP而不是.htaccess或web.config文件来处理问题,因为它更易于移植,并且更易于在开发和登台服务器上进行测试。我同时处理数据库连接,因为它们在开发/登台/生产服务器之间也有所不同。

这是我典型代码的简化版本。请注意规范重定向到最后。

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   


评论


我通常是通过Apache虚拟主机完成主机规范化的,而不是通过代码进行处理。看来Apache可以将HTTP主机名与带或不带尾点的虚拟主机匹配,但是您可以看到代码中是否有带尾点的主机。

–斯蒂芬·奥斯特米勒(Stephen Ostermiller)
2014年12月19日上午11:23

#3 楼

我在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),(通用Internet方案)URL的“主机”部分始终是完全合格的域名,并且不适用区分完全合格的域名和不完全合格的域名的常规机制。无论是example.com。

-我认为他是不对的,根据rfc 1738,我认为网址完全不允许使用“ example.com”,它在第二个文本中引用,我引用了它:

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


当时“ http.header”中不能使用“ example.com”,因为rfc 1738是1994年的版本,主机字段仅在1997年的http 1.1中出现(您可以在Wikipedia中查看)。

因此,实际上,仅fqdn保留在网址中。我认为,这是rfc 1738中的错误,因为以这种方式,它(试图使)“相对域”功能无效。如果没有禁止,理论上讲,如果浏览器和服务器支持,则可以在本地脚本站点的“ a”标签hrefs或使用相对域的大公司中的静态html文档中使用它们。但是即使rfc 1738禁止使用它们,人们也没有听从:他们继续以相对形式使用顶级域名,即没有尾随点,因此rfc 1738禁止使用的内容无论如何都不是一个大的实际问题,人们不得不使用替代方法相对域:他们只是将本地顶级域设置为“本地主机”(例如“ localhost”),并且也使用并使用了它们而没有尾随点。

然后他说:

不幸的是,实际上,在将主机名映射到一组IP地址时,Web浏览器始终违反该规范,并通过其DNS客户端库的名称限定过程传递了“主机”部分。 (例如,那些使用BIND DNS客户端库的用户将保留RES_DNSRCH选项,并且如果丢失了最后的结尾点,则不会附加最后的结尾点。)

-我认为他的意思是主机没有结尾应该将点号作为错误抛出,并且仅将绝对域(fqdn)传递给dns。我认为可能浏览器确实将所有域都传递给了dns,因为人们使用了他们自定义的本地顶级域,例如“ localhost”。而且无论如何,后来在1998年发布的rfc 2396中,允许在网址中使用顶级域名而没有结尾点。根据既定的人类行为,即事实上的标准,他说,最好是浏览器遵守rfc 1738,并建议所有人按照rfc 1738的命令在所有地方仅使用fqdn。

-但是,如果人们遵守RFC 1738会发生什么?像“ http://example.com/test.html”和“ http://localhost/test.html”之类的网址都必须改写为“ http://example.com./test.html”和“ http ://localhost./test.html”。浏览器将不得不将没有点的主机标记为错误,或者将其重定向为完整/绝对形式的主机。所有配置本地顶级域(如“ localhost”)的人都必须将其服务器配置为仅接受对域名(如“ localhost”)的请求。 ,或接受并将[本地主机]中的所有URL重定向到[本地主机]中的相应URL。像“ localhost”这样的文本仅在浏览器地址栏中键入时才有用,但这将是非常无用的用法,并且不需要相对域功能,因为浏览器会在键入时搜索域。在html源代码中使用它们将变得无用,因为这将导致此类链接不起作用,或者单击所有带有“ localhost”的链接会将用户移至“ localhost”。并且每次点击(在此类链接上)都将获得额外的重定向。因此,rfc 1738将使计划的“相对域”功能完全无用。如果某个公司使用了该功能,并且在本地站点中使用了它们的相对域,并且带有相对域的url没有被浏览器重定向到绝对格式,那么它们的站点就可以正常工作,如果他们也遵循rfc 1736,他们将配置服务器只接受fqdn,则他们要么必须用fqdn重写所有此类URL,要么在每次单击此类URL时进行额外的重定向。如果该公司喜欢使用“ team101”之类的短域名而不是“ team101.microsoft.com”。在其地址栏和html源中,他们将必须开始使用其自定义的内部顶级域,例如“ team101”。即像“本地主机”。而不是“ team101.microsoft.com”之类的子域。 (在他们决定遵循rfc 1738之前可以用作“ team101”)。

-

而且我发现,RFC 1738大力支持的尾随点实际上仅在不带尾随点的标准之后出现!它在1987年与rfc 1034一起出现,在第二个链接中被引用,我引用了它:

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(1987年)仅声明了所有使用时,似乎它们都没有尾随点,将它们全部声明为相对域!但他们仍然像以前一样工作,因此可能很少有人对此有所了解,并继续认为当他们使用“ example.com”时不加任何结尾时,他们无疑会要求一个唯一的真实“ example.com”网站。因此,在某些情况下,这又成为一个额外的安全漏洞:子域管理员可能会欺骗著名的真实example.com,即使他没有获得创建任何本地域(如“ localhost”)的权限。因此,rfc 1034的设计也不是很好:似乎它的作者并不希望它会{不广为人知,因此造成安全漏洞}!

可能是rfc 1738(1994)最终尝试将绝对域和相对域之间的区别的概念带给广大受众,并修复了6年后的安全漏洞,{但是通过禁止URL中的相对域来修复安全漏洞,使得相对域无用,{但我认为它们可能没有被广泛使用,可能仅在某些大公司中使用}}。因此,如果遵守,那么RFC 1737的结果将是什么[左]? -1)1987年声明的相对域最终将变得无用,因此,用于显示绝对域的尾随点也将最终变得无用和多余的“合法”(即由rfcs定义)! (但也许他们计划了多年以后,当广大受众(公众)开始了解相对域的可能性时,才在URL中重新允许相对域)。 2)和rfc 1737(如果遵守的话)也可以解决安全漏洞。 -但是,即使rfc 1034大规模传播,也不会造成安全漏洞,并且众所周知,使用相对域并不安全! -因此,解决该问题的主要方法是吸引广泛的受众,而发布更多的rfc只是实现该问题的许多方法之一。

我现在认为相对领域功能可能尚未广泛在RFC 1034(1987年)之后才知道,因为它的用途太有限:仅在某些大公司或提供商的本地网络中使用,并且它是一项没有实际价值的功能,因为本地网络已经可以建立任何本地域,因此该功能只是为了自己,实际上这只是rfc中无用的文本,任何人都应该知道和使用,而没有任何额外的好处!但是当浏览器开始服从它时,人们通过广泛忽略rfc造成了很少的安全漏洞。

我昨天检查了相对域名功能,它可以工作。 (没关系,因为rfc 2396(1998年)在rfc 1034(1987年)被拒绝之后又允许了它,后来rfc 3986(2005年)仍然允许它们)。我在Windows 10中添加了dns后缀-控制面板-...-网络设备属性-ipv4属性-其他-dns选项卡。当我添加“ google.com”然后在firefox中打开“ http:// mail /”时,它打开了google的服务器,但未配置为仅在http“主机”标头中使用“邮件”,所以我得到了一些东西类似于“ 404”页面。

-

我通过第二个链接(http://www.dns-sd.org/trailingdotsindomainnames.html)答复了文本。 :

他还引用了rfc 1738中的规则,并说:

不幸的是,实现Web浏览器客户端的人们似乎并不理解这意味着什么。当您访问网站时,在应用DNS用户的搜索列表来构造DNS服务器中的标准名称之后,大多数网络浏览器在“主机:”字段中输入的值是用户键入的内容,而不是计算机最终实际使用的内容。部分名称。例如,这是用户可以参考主机“ www.example.com”的三种不同方式。 ...在将“ Host:”参数发送到Web服务器时,Web浏览器客户端将输入用户键入的内容(“ www.example.com。”,“ www.example.com”或“ www”)客户端最终在DNS中查找的内容(在所有三种情况下均为“ www.example.com。”)。 ...

-这不是很正确(正确),因为rfc 1738在这方面非常严格,并且即使在浏览器的地址栏中,它也不允许所有url中的相对域,并且url本身是对网站进行任何引用的[推荐]方法,即使人们将其写在纸上,因此rfc 1738不允许用户以这3种方式引用该网站,前提是该用户打算认为他们使用了URL!

似乎该文本的作者(Stuart Cheshire)不了解rfc 2396,因此此文本已过时。

-

现在情况如何? rfc 3986(https://tools.ietf.org/html/rfc3986#page-21)允许引用绝对域而不会在末尾加点:它表示“ DNS中完全限定域名的最右边域标签后可以跟一个单个“。”,如果“必须在完整域名和某些本地域之间进行区分”,则应使用它。我认为由于事实上的标准,几乎没有必要,因此wordpress可以接受事实的标准,并从带有尾点的地址重定向到没有它的地址。