웹 사이트는 후행 점으로 호스트 이름을 어떻게 처리해야합니까?

이 질문을 읽었습니다 . URL에 점이 어떻게있을 수 있습니까? 예를 들어 www.bla.de.? FQDN에는 .DNS 트리의 루트 레이블에 대한 후행이 포함되어야합니다 .

example.com. 대신에 example.com

그러나이 블로그 기사 에서 지적한 바와 같이 문제가 있습니다 .

사용자가 실수로 끝에 점이있는 도메인 이름을 입력하거나 일부 "잘 알려진 사람"으로부터받은 링크를 따라 끝에 점이있는 도메인 이름을 얻을 수 있다는 사실을 고려하지 않으면 결과 예기치 않은 결과가 발생할 수 있습니다.

1) 웹 사이트에서 HTTPS를 사용하는 경우 끝에 점이있는 도메인 이름으로 이동하면 신뢰할 수없는 연결에 대한 경고가 브라우저에 표시됩니다.

2) 쿠키는 일반적으로 끝에 점이없는 도메인 이름으로 쿠키가 설정되므로 인증이 중단 될 수 있습니다. 이 경우 사용자가 로그인 할 수없는 이유에 대해 매우 놀랄 것입니다. 끝에 점이있는 도메인 이름에 쿠키를 설정하면이 쿠키는 점이없는 도메인 이름으로 전달되지 않습니다. 끝에서 그리고 그 반대로.

3) 페이지의 JavaScript가 손상되었을 수 있습니다.

4) 웹 사이트 페이지 캐싱에 문제가있을 수 있습니다 (예를 들어, https://www.cloudflare.com/도메인 이름에 유효하지 않은 도메인 이름으로 간주되는 끝에 도메인 이름이 있으면 페이지 캐시를 지우지 않습니다).

5) 웹 서버 구성의 조건에서 끝에 점이없는 특정 도메인 이름 (Nginx의 $ http_host, Apache의 % {HTTP_HOST})에 의존하는 경우 예기치 않은 리디렉션, 기본 등 다양한 예기치 않은 상황이 발생할 수 있습니다. 인증 문제 등

6) 웹 서버가 후행 점으로 도메인 이름에 대한 요청을 수락하도록 구성되지 않은 경우 실수로 후행 점으로 도메인 이름을 입력 한 사용자에게는 잘못된 요청-잘못된 호스트 이름과 같은 것이 표시됩니다.

7) 누군가가 실수로 또는 고의로 도메인 이름 끝에 점이있는 웹 페이지 링크를 게시하는 경우 검색 엔진이 리소스에 중복 된 콘텐츠가 있음을 발견 할 수 있습니다.

나는 또한 그 실현 http://webmasters.stackexchange.com./않습니다 400 Bad Request. 그러나 적절한 도메인 이름 .끝에 끝에 포함 해야 하므로 끝에 점이없는 호스트 이름에 대해 400오류를 발생 시키거나 301리디렉션하지 않아야합니까? 일관되고 일관된 방식으로이 문제를 처리하는 올바른 방법은 무엇입니까?

질문에 부분적으로 답하기 위해 htaccess 표준 전달자 규칙에 질문을 추가 할 수 있습니다. 기본 HTTP 의미에서는 URI 전에 마침표를 찾아 사용하는 중복 방지 전달 메커니즘으로 작동합니다. 다음은 일반적인 "addon 도메인"하위 유틸리티 경로를 포함하는 예입니다.

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\/$1" [R=301,L]

이 작업은 다음을 모두 표준 HTTP www 도메인으로 전달하는 것입니다.

• 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을 전달하지 제대로하고 (특히 HSTS로) 대부분의 서버 인스턴스에서 브라우저 경고 또는 400 잘못된 요청 오류가 날 것입니다. 이는 TTL 이후 사용 사례에서 "호스트"SSL을 확인하기 때문입니다. 호스트 SSL 경고가 htaccess 및 사물보다 먼저 발생하기 때문에 호스트 SSL 경고를 처리하는 해결 방법이 확실하지 않습니다.

나는 후행 점을 인터넷의 "진정한"루트로 생각하고 미국 버지니아에 살고 있다고 생각합니다. 점을 제외하면 일부 루트가 항상 암시됩니다. 일반 사용자의 경우 동일한 루트이며 오늘 논의 할 상황입니다.

난처한 방식으로 실제로 후행 점이 매우 편리하다는 것을 알았습니다. 다른 사람의 웹 사이트를 체크 아웃하고 캐싱, 쿠키 등을 사용하지 않고 새로 시작하고 너무 늦어서 쿠키를 플러시하지 않으면 다른 브라우저를 사용하거나 점을 추가합니다. 사이트가 나를 리디렉션하지 않으면 모든 사이트 페이지 및 기타 리소스에 대해 캐시되지 않은 완전히 새로 워진 URL이 있습니다.

웹 마스터로서 페이지를 보는 모든 사람과 로봇이 동일한 URL과 동일한 호스트 이름으로 페이지를 보길 원합니다. 호스트 이름이 내가 사용하고 싶지 않은 경우 즉시 301 리디렉션을 수행하여 브라우저에서 올바른 URL을 볼 수 있습니다. PHP 기반 사이트의 경우 .htaccess 또는 web.config 파일이 아닌 PHP에서 문제를 처리합니다. 이식성이 뛰어나고 개발 및 스테이징 서버에서 테스트하기가 쉽기 때문입니다. 데이터베이스 연결도 개발 / 스테이징 / 생산 서버에 따라 다르므로 동시에 데이터베이스 연결을 처리합니다.

다음은 일반적인 코드의 단순화 된 버전입니다. 정식 리디렉션은 끝으로 향합니다.

    $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");
    }   

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)에 정의 된 바와 같이 (공통 인터넷 체계) URL의 "호스트"부분은 정규화 된 도메인 이름이며 정규화 된 도메인 이름과 비정규 화 된 도메인 이름을 구분하는 일반적인 메커니즘이었습니다. 정규화 된 도메인 이름이 적용되지 않았습니다. example.com인지 여부 또는 example.com에서 호스트는 동일하도록 설계되었습니다.

-나는 그가 옳지 않다고 생각합니다. "fc.738"에 따르면 "example.com"은 URL에 전혀 허용되지 않았다고 생각합니다. 두 번째 텍스트에 인용되어 있습니다.

3.1. 일반적인 인터넷 체계 구문
        // <user> : <password> @ <host> : <port> / <url-path>
    주최자
        네트워크 호스트의 정규화 된 도메인 이름

rfc 1738은 1994 년이고 호스트 필드는 1997 년에 http 1.1로만 나타났기 때문에 "example.com"은 http 헤더에서 사용할 수 없습니다 (wikipedia에서 확인할 수 있음).

따라서 실제로 URL에는 fqdn 만 허용되었습니다. 나는 이것이 rfc 1738의 오류라고 생각한다. "상대 도메인"기능을 쓸모 없게 만들었 기 때문이다. 허용하지 않는 경우 이론적으로 로컬 스크립팅 사이트의 "a"태그 href 또는 브라우저와 서버에서 지원하는 경우 상대 도메인을 사용하는 대기업의 정적 HTML 문서에서 사용될 수 있습니다. 그러나 rfc 1738이 그들을 허용하지 않더라도 사람들은 그것을 따르지 않았습니다. 그들은 상대적인 형태로 최상위 도메인을 계속 사용했습니다. 즉, 후행 점은 없었습니다. 상대 도메인으로 : "localhost"와 같은 로컬 최상위 도메인을 만들었습니다 (점을 사용하지 않고 사용함).

그리고 그는 말한다 :

불행히도, 실제로 웹 브라우저는 해당 사양을 위반하고 호스트 이름을 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 "및"http://localhost./test.html". 브라우저는 점이없는 호스트를 오류로 표시하거나이를 클릭하여 전체 / 절대 형태로 리디렉션해야합니다."localhost "와 같은 로컬 최상위 도메인을 구성한 모든 사용자는 요청 만 수락하도록 서버를 구성해야합니다. "localhost."와 같은 도메인의 경우, 또는 [localhost "와 같은 [localhost]에있는 [local url]에있는 [local url]을 [localhost."로 받아들이고 리디렉션합니다. "localhost"와 같은 텍스트는 브라우저 주소 표시 줄에 입력 할 때만 유용합니다. 브라우저는 입력시 도메인을 검색하기 때문에 매우 쓸모없는 사용법 일 뿐이며 상대 도메인 기능은 필요하지 않습니다 .html 소스에서 도메인을 사용하면 그러한 링크가 작동하지 않거나 모두 클릭하기 때문에 쓸모 없게됩니다 "localhost"와의 링크는 사용자를 "localhost"로 이동시킵니다."와 같은 링크에서 클릭 할 때마다 추가로 리디렉션됩니다. 따라서 rfc 1738은 계획된"상대 도메인 "기능을 전혀 쓸모 없게 만들 것입니다. 일부 회사에서 해당 기능을 사용하고 로컬 사이트에서 상대 도메인을 사용하는 경우, 상대 도메인을 가진 URL은 브라우저에 의해 절대 형식으로 리디렉션되지 않았으므로 사이트는 정상적으로 작동했습니다. rfc 1736을 준수하면 서버는 fqdn 만 허용하도록 서버를 구성하고 해당 URL을 모두 다시 작성해야합니다 fqdn 또는 해당 URL을 클릭 할 때마다 추가 리디렉션 작업을 수행하는 경우 회사가 주소 표시 줄과 html 소스에 "team101.microsoft.com"대신 "team101"과 같은 짧은 도메인을 선호하는 경우 사용을 시작해야합니다 "team101"과 같은 맞춤 내부 최상위 도메인 (예 : ""team101.microsoft.com"과 같은 하위 도메인 대신 localhost. "(rfc 1738을 준수하기로 결정하기 전에"team101 "으로 사용될 수 있음).

-

그리고 rfc 1738에 의해 매우 강력하게 뒷받침되는 후행 점은 실제로 후행 점없이 표준 이후에만 나타납니다! 그것은 1987 년에 rfc 1034와 함께 나타 났으며 두 번째 링크에서 인용되었습니다.

완전한 도메인 이름은 루트 레이블로 끝나기 때문에
점으로 끝나는 인쇄 양식. 이 속성을 사용하여 다음을 구분합니다.
-완전한 도메인 이름을 나타내는 문자열
 (종종 "절대"라고 함). 예를 들어 "poneria.ISI.EDU"
-시작 레이블을 나타내는 문자열
 불완전하고 다음에 의해 완료되어야하는 도메인 이름
 로컬 도메인에 대한 지식을 사용하는 로컬 소프트웨어
 "상대적"이라고 함). 예를 들어 "poneria"는
 ISI.EDU 도메인.

rfc 1034 (1987)는 방금 사용 된 모든 도메인을 선언했으며, 모두 점이없는 것으로 보이며, 모두 상대 도메인이되는 것으로 선언했습니다! 그러나 그들은 여전히 ​​이전과 같이 일했기 때문에 아마 그것에 대해 아는 사람은 거의 없었으며, 그들이 "example.com"을 후행없이 사용할 때 고유 한 실제 "example.com"사이트를 분명하게 요구한다고 생각했습니다. "localhost"와 같은 로컬 도메인을 만들 권한이없는 경우에도 하위 도메인 관리자가 유명한 실제 example.com을 스푸핑 할 수 있습니다. 따라서 rfc 1034는 잘 설계되지 않았습니다. 작성자가 {아주 널리 알려지지 않았으므로 보안 위반을 일으킬 것입니다. "

아마도 rfc 1738 (1994)은 최종적으로 절대 도메인과 상대 도메인의 구별 아이디어를 광범위한 대상에게 제공하고 6 년 후에 보안 침해를 해결하려고 시도했지만 {그러나 상대 도메인을 URL에서 상대 도메인을 사용할 수 없도록하여 보안 위반을 수정함으로써 , (하지만 아마도 그들은 일부 대기업에서만 널리 사용되지는 않았을 것입니다}}. 그렇다면, rfc 1737의 결과에 따를 경우 어떤 것이 남게됩니까? -1) 1987 년에 선언 된 상대 도메인은 결국 쓸모 없게되므로 절대 도메인을 나타내도록 설계된 후행 점은 결국 쓸모없고 중복 될 수있다. (그러나 그들은 나중에 여러 사람 (일반 대중)이 상대 도메인의 가능성에 대해 알기 시작한 후 몇 년 후에 URL에서 상대 도메인을 다시 허용하도록 계획했을 것입니다). 2) 및 rfc 1737, 준수한 경우 보안 위반도 수정합니다. 그러나 rfc 1034조차도 대중에 도달하면 보안 침해를 일으키지 않으며 상대 도메인을 사용하는 것이 안전하지 않다는 것이 널리 이해되었습니다! 따라서이를 해결하기위한 주요 레시피는 많은 사람들에게 도달하는 것이 었으며, 하나 이상의 rfc를 게시하는 것은 여러 가지 방법 중 하나 일뿐입니다.

상대 도메인 기능은 rfc 1034 (1987 년) 이후 널리 사용되지 않았기 때문에 사용이 너무 제한적 이었기 때문에 일부 대기업이나 공급 업체의 로컬 네트워크에서만 가능하며 실질적인 가치가없는 기능이었습니다. 로컬 네트워크는 이미 로컬 도메인을 만들 수 있었기 때문에 그 기능은 그 자체로만 사용되었으므로 실제로 추가 혜택없이 누구나 알고 사용해야하는 rfc의 쓸모없는 텍스트였습니다! 그러나 사람들은 rfc를 광범위하게 무시하여 보안 침해를 거의 일으키지 않았지만 브라우저는이를 준수하기 시작했습니다.

어제 상대 도메인 기능을 확인했는데 작동합니다. (1987 년의 rfc 2396이 1987 년의 rfc 1034가 거부 된 후 다시 허용했고, 이후 rfc 3986 (2005 년)이 여전히 허용하기 때문에 괜찮습니다). Windows 10-제어판-...-네트워크 장치 속성-ipv4 속성-추가-dns 탭에 dns 접미사를 추가했습니다. "google.com"을 추가 한 후 "파이어 폭스에서 http : // mail / ", 구글 서버를 열었지만 http"호스트 "헤더에서"메일 "로 작동하도록 구성되지 않았으므로"404 "페이지와 같은 것을 얻었습니다.

-

두 번째 링크로 텍스트에 대한 답장 ( http://www.dns-sd.org/trailingdotsindomainnames.html ) :

그는 rfc 1738의 규칙을 인용하고 말합니다.

불행히도, 웹 브라우저 클라이언트를 구현하는 사람들은 이것이 무엇을 의미하는지 이해하지 못하는 것처럼 보였습니다. 웹 사이트에 액세스 할 때 대부분의 웹 브라우저가 "호스트 :"필드에 입력 한 값은 DNS 사용자의 검색 목록을 적용하여 컴퓨터에서 정규화 된 이름을 구성한 후 컴퓨터가 실제로 사용한 결과가 아니라 사용자가 입력 한 값입니다. 부분 이름. 예를 들어 다음은 사용자가 호스트 "www.example.com"을 참조 할 수있는 세 가지 방법입니다. ... "Host :"매개 변수를 웹 서버로 보낼 때 웹 브라우저 클라이언트는 사용자가 입력 한 내용 ( "www.example.com.", "www.example.com"또는 "www")을 대신 입력합니다. 클라이언트가 실제로 DNS에서 조회 한 결과 (세 가지 경우 모두 "www.example.com.") ...

-rfc 1738은 이와 관련하여 매우 엄격하기 때문에 브라우저의 주소 표시 줄에 있지만 URL 자체가 [권장]하는 방법이지만 모든 URL에서 상대 도메인을 허용하지 않기 때문에 이것은 매우 사실이 아닙니다. 사람들이 종이에 작성하더라도 사이트에 대한 언급은 사용자가 URL을 사용한 것으로 생각한다면 rfc 1738에 의해 3 가지 방식으로 해당 사이트를 참조하는 것이 허용되지 않았습니다!

이 글의 저자 (Stuart Cheshire)는 rfc 2396에 대해 몰랐기 때문에이 글은 구식입니다.

-

요즘 상황은 어떻습니까? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 )에는 후행 점없이 절대 도메인을 참조 할 수 있습니다. "DNS에서 정규화 된 도메인 이름의 가장 오른쪽 도메인 레이블 뒤에 단일"이있을 수 있습니다. " ""이며 전체 도메인 이름과 일부 로컬 도메인을 구별해야하는 경우 사용해야합니다. 나는 사실상의 표준으로 인해 거의 필요하지 않다고 생각하므로 워드 프레스는 사실상의 표준을 수락하고 후행 점이있는 주소에서 주소가없는 주소로 리디렉션 할 수 있습니다.