Làm thế nào các trang web nên xử lý tên máy chủ với dấu chấm?

Tôi đọc câu hỏi này Làm thế nào URL có thể có một dấu chấm. ở cuối, ví dụ: www.bla.de.? và nhận ra rằng FQDN nên chứa một dấu vết .cho nhãn gốc của cây DNS:

example.com. thay vì example.com

Tuy nhiên, có những vấn đề như được chỉ ra trong bài viết trên blog này :

Nếu bạn không xem xét thực tế rằng người dùng có thể vô tình nhập tên miền có dấu chấm ở cuối hoặc theo liên kết nhận được từ một số "người đánh bóng tốt" và nhận được tên miền của bạn bằng dấu chấm ở cuối, như là kết quả là nó có thể dẫn đến hậu quả không mong muốn:

1) Nếu trang web sử dụng HTTPS, khi điều hướng đến tên miền có dấu chấm ở cuối, trình duyệt sẽ hiển thị cảnh báo về kết nối không tin cậy.

2) Xác thực có thể bị hỏng, vì cookie thường được đặt cho tên miền không có dấu chấm ở cuối. Người dùng trong trường hợp này sẽ khá ngạc nhiên tại sao anh ta không thể đăng nhập. Điều đáng chú ý là nếu bạn đặt cookie cho một tên miền có dấu chấm ở cuối, cookie này sẽ không được chuyển sang tên miền mà không có dấu chấm ở cuối và ngược lại.

3) JavaScript trên trang có thể bị hỏng.

4) Có thể có vấn đề với bộ đệm của các trang web (ví dụ: https://www.cloudflare.com/không xóa bộ đệm trang nếu tên miền có dấu chấm ở cuối coi đó là tên miền không hợp lệ).

5) Nếu trong điều kiện trong cấu hình máy chủ web, bạn dựa vào tên miền cụ thể ($ http_host trong Nginx,% {HTTP_HOST} trong Apache) mà không có dấu chấm ở cuối, bạn có thể gặp nhiều tình huống bất ngờ: chuyển hướng bất ngờ, cơ bản vấn đề tác giả, vv

6) Nếu máy chủ web không được định cấu hình để chấp nhận các yêu cầu trên tên miền có dấu chấm, bất kỳ người dùng nào vô tình gõ tên miền có dấu chấm sẽ thấy một cái gì đó như Yêu cầu xấu - Tên máy chủ không hợp lệ.

7) Có thể các công cụ tìm kiếm có thể thấy rằng tài nguyên của bạn có nội dung trùng lặp, nếu ai đó vô tình hoặc cố ý đăng liên kết đến các trang web của bạn bằng một dấu chấm ở cuối tên miền.

Tôi cũng nhận ra rằng http://webmasters.stackexchange.com./a 400 Bad Request. Nhưng vì tên miền thích hợp nên chứa một .phần cuối, chúng ta không nên đưa ra 400lỗi hoặc 301chuyển hướng cho tên máy chủ mà không có dấu chấm? Cách thích hợp để giải quyết vấn đề này một cách mạch lạc và nhất quán là gì?

Để trả lời một phần câu hỏi của bạn, bạn có thể thêm nó vào quy tắc chuyển tiếp chính tắc htaccess. Theo nghĩa HTTP cơ bản, nó tìm kiếm một khoảng thời gian trước URI và vận hành nó thành bất kỳ cơ chế chuyển tiếp chống trùng lặp nào bạn sử dụng. Dưới đây là một ví dụ bao gồm một tuyến sử dụng phụ "tên miền addon" phổ biến:

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]

Điều này sẽ làm là chuyển tiếp tất cả những điều sau đây đến một tên miền HTTP www chuẩn:

• tên miền.hostdomain.com
• tên miền.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• tên miền.com
• tên miền.com.
• www.domain.com.

Tất cả chuyển tiếp đến:

• http://www.domain.com

Mặc dù vậy, có một sự cảnh báo - như đã nêu trong trích dẫn blog ban đầu, SSL sẽ không chuyển tiếp chính xác và sẽ đưa ra cảnh báo trình duyệt hoặc 400 lỗi yêu cầu xấu trong hầu hết các trường hợp máy chủ (đặc biệt là với HSTS). Điều này là do nó nhìn thấy SSL "máy chủ" trong trường hợp sử dụng sau giai đoạn TLD. Tôi không chắc chắn một cách giải quyết để đối phó với cảnh báo SSL máy chủ vì nó xuất hiện trước htaccess và mọi thứ.

Tôi thích nghĩ về dấu chấm là "gốc" thực sự của Internet và nó sống ở Virginia, Hoa Kỳ. Nếu bạn để lại dấu chấm, thì một số root luôn được ngụ ý. Đối với người dùng bình thường, đó là cùng một gốc, và đó là tình huống tôi sẽ thảo luận hôm nay.

Theo cách sai lầm của tôi, tôi thực sự thấy dấu chấm khá tiện dụng. Nếu tôi đang kiểm tra trang web của người khác và tôi muốn bắt đầu mới, không lưu vào bộ nhớ cache, không có cookie, v.v. và tôi quá lười để xóa chúng, tôi sẽ sử dụng một trình duyệt khác hoặc tôi sẽ thêm dấu chấm. Nếu trang web không chuyển hướng cho tôi, tôi đã nhận được URL hoàn toàn mới cho tất cả các trang của trang web và các tài nguyên khác.

Là một quản trị trang web, tôi muốn tất cả mọi người và robot xem một trang sẽ xem nó với cùng một URL và do đó có cùng tên máy chủ. Nếu tên máy chủ không phải là tên tôi muốn họ sử dụng, tôi sẽ thực hiện chuyển hướng 301 ngay lập tức để họ sẽ thấy URL chính xác trong trình duyệt của họ. Đối với các trang web dựa trên PHP của tôi, tôi xử lý sự cố trong PHP chứ không phải trong tệp .htaccess hoặc web.config, vì nó dễ mang theo hơn và dễ kiểm tra hơn trên các máy chủ phát triển và dàn dựng. Tôi xử lý các kết nối cơ sở dữ liệu của mình cùng một lúc, vì chúng cũng khác nhau giữa các máy chủ phát triển / dàn / sản xuất.

Đây là một phiên bản đơn giản hóa mã điển hình của tôi. Lưu ý các chuyển hướng chính tắc về cuối.

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

nhận xét của tôi tại https://core.trac.wordpress.org/ticket353248#comment:9 :

trả lời của tôi cho văn bản bằng liên kết đầu tiên ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Ban đầu, như được định nghĩa trong RFC 1738 (§ 3.1), phần "máy chủ" của URL (Lược đồ Internet chung) luôn luôn là một tên miền đủ điều kiện và cơ chế thông thường để phân biệt tên miền đủ điều kiện với tên miền không đầy đủ tên miền đủ điều kiện đã không áp dụng. Cho dù đó là example.com. hoặc example.com, máy chủ được dự định là giống nhau.

- tôi nghĩ anh ấy không đúng, tôi nghĩ "example.com" hoàn toàn không được phép trong các url theo rfc 1738, nó được trích dẫn trong văn bản thứ hai và tôi trích dẫn nó:

3.1. Cú pháp Internet chung
        // <người dùng>: <mật khẩu> @ <máy chủ>: <cổng> / <url-path>
    tổ chức
        Tên miền đủ điều kiện của máy chủ mạng

và "example.com" không thể được sử dụng trong các tiêu đề http tại thời điểm đó, bởi vì rfc 1738 là của năm 1994 và trường máy chủ chỉ xuất hiện với http 1.1 vào năm 1997 (bạn có thể kiểm tra trong wikipedia).

vì vậy, thực sự, chỉ có fqdn được phép trong các url. Tôi nghĩ rằng, đây là một lỗi trong rfc 1738, bởi vì theo cách đó nó đã làm (cố gắng thực hiện) tính năng "miền tương đối" vô dụng. nếu nó không cho phép, về mặt lý thuyết, chúng có thể được sử dụng trong "a" tag href trong các trang web kịch bản cục bộ hoặc tài liệu html tĩnh bên trong các công ty lớn sử dụng tên miền tương đối, nếu trình duyệt và máy chủ hỗ trợ. nhưng ngay cả khi rfc 1738 không cho phép họ, mọi người vẫn không tuân theo: họ vẫn tiếp tục sử dụng các tên miền cấp cao nhất ở dạng tương đối, ví dụ như không có dấu chấm, do đó, điều này không được chấp nhận bởi rfc 1738 dù sao cũng không phải là vấn đề thực tế lớn. đến các tên miền tương đối: họ chỉ tạo các tên miền cấp cao nhất cục bộ như "localhost" (và được sử dụng và sử dụng chúng mà không có dấu chấm).

sau đó anh nói:

Thật không may, trong thực tế, các trình duyệt web luôn vi phạm thông số kỹ thuật đó và đã chuyển phần "máy chủ" thông qua các quy trình xác định tên của thư viện Máy khách DNS của họ khi ánh xạ tên máy chủ thành một bộ địa chỉ IP. (Ví dụ: những người đã sử dụng thư viện BIND DNS Client sẽ để tùy chọn RES_DNSRCH được đặt và sẽ không nối thêm dấu chấm cuối cùng nếu nó bị thiếu.)

- tôi nghĩ rằng anh ta có nghĩa là các máy chủ không có dấu chấm nên bị bỏ qua vì lỗi và chỉ các miền tuyệt đối (fqdn) mới được chuyển đến dns. Tôi nghĩ có lẽ các trình duyệt đã chuyển tất cả các tên miền sang dns vì mọi người đã sử dụng các tên miền cấp cao nhất tùy chỉnh cục bộ của họ như "localhost". và dù sao, sau này trong rfc 2396 được xuất bản năm 1998, việc sử dụng các tên miền cấp cao nhất trong các url mà không có dấu chấm được cho phép.

sau đó tác giả (Jonathan de Boyne Pollard) trích dẫn rfc 2396 và hối hận về việc nó đã thay đổi theo hành vi của con người đã được xác định, ví dụ như trên thực tế, nói rằng sẽ tốt hơn nếu các trình duyệt tuân theo rfc 1738 và khuyên mọi người chỉ nên sử dụng fqd, trong tất cả các nơi, như được chỉ huy bởi rfc 1738.

- nhưng điều gì sẽ xảy ra nếu mọi người tuân theo rfc 1738? url như "http://example.com/test.html "và"http: //localhost/test.html "tất cả phải được viết lại thành"http://example.com./test.html "và"http://localhost./test.html". trình duyệt sẽ phải đánh dấu máy chủ mà không có dấu chấm là lỗi hoặc chuyển hướng khi nhấp vào chúng ở dạng đầy đủ / tuyệt đối. Tất cả những người đã định cấu hình tên miền cấp cao nhất cục bộ như" localhost "sẽ phải định cấu hình máy chủ của họ để chỉ chấp nhận yêu cầu đối với các tên miền như "localhost." hoặc chấp nhận và chuyển hướng [tất cả các url bên trong] "localhost" sang [url tương ứng trong] "localhost.". văn bản như "localhost" sẽ chỉ hữu ích khi nhập nó vào thanh địa chỉ trình duyệt, nhưng điều đó sẽ chỉ sử dụng rất vô dụng và tính năng tên miền tương đối không cần thiết cho điều đó, bởi vì các trình duyệt tìm kiếm tên miền khi nhập. Việc sử dụng chúng trong nguồn html sẽ trở nên vô dụng vì nó sẽ dẫn đến các liên kết như vậy sẽ không hoạt động hoặc nhấp vào tất cả liên kết với "localhost" sẽ chuyển người dùng đến "localhost."và nó sẽ chỉ là chuyển hướng thêm vào mỗi lần nhấp (trên các liên kết như vậy). Vì vậy, rfc 1738 sẽ làm cho tính năng" miền tương đối "được lên kế hoạch hoàn toàn vô dụng. Nếu một số công ty sử dụng tính năng đó và sử dụng tên miền tương đối của họ trong các trang web địa phương của họ, và các url của họ với các miền tương đối không được chuyển hướng thành dạng tuyệt đối bởi các trình duyệt, vì vậy các trang web của họ hoạt động bình thường, nếu họ cũng tuân theo rfc 1736, họ sẽ cấu hình máy chủ của họ để chỉ chấp nhận fqdn và họ sẽ phải viết lại tất cả các url như vậy với fqdn hoặc làm việc với chuyển hướng bổ sung trên mỗi lần nhấp vào các url như vậy. nếu các công ty đó thích có tên miền ngắn như "team101" thay vì "team101.microsoft.com." trong thanh địa chỉ và nguồn html, họ sẽ phải bắt đầu sử dụng tên miền cấp cao nội bộ tùy chỉnh của họ như "team101." tức là như "localhost. "thay vì các tên miền phụ như" team101.microsoft.com. "(có thể được sử dụng như" team101 "trước khi họ quyết định tuân theo rfc 1738).

-

và tôi đã phát hiện ra rằng dấu chấm, được hỗ trợ rất mạnh bởi rfc 1738, thực sự chỉ xuất hiện sau khi nổi bật mà không có dấu chấm! nó xuất hiện với rfc 1034 vào năm 1987, nó được trích dẫn trong liên kết thứ hai và tôi đã trích dẫn nó:

Vì một tên miền hoàn chỉnh kết thúc bằng nhãn gốc, điều này dẫn đến một
mẫu in kết thúc bằng dấu chấm. Chúng tôi sử dụng tài sản này để phân biệt giữa:
- một chuỗi ký tự đại diện cho một tên miền hoàn chỉnh
 (thường được gọi là "tuyệt đối"). Ví dụ: "poneria.ISI.EDU."
- một chuỗi ký tự đại diện cho các nhãn bắt đầu của một
 tên miền không đầy đủ và phải được hoàn thành bởi
 phần mềm cục bộ sử dụng kiến ​​thức về miền địa phương (thường
 gọi là "họ hàng"). Ví dụ: "poneria" được sử dụng trong
 Tên miền ISI.EDU.

rfc 1034 (năm 1987) vừa khai báo tất cả các tên miền đã được sử dụng, dường như tất cả chúng đều không có dấu chấm, tuyên bố tất cả chúng là các miền tương đối! nhưng họ vẫn làm việc như trước đây, vì vậy có lẽ ít người biết về điều đó và tiếp tục nghĩ rằng họ rõ ràng yêu cầu một trang web "example.com" thực sự độc đáo khi họ sử dụng "example.com" mà không có dấu chấm. do đó, điều đó đã trở thành một vi phạm bảo mật bổ sung trong một số trường hợp: example.com thật nổi tiếng có thể bị quản trị viên tên miền giả mạo ngay cả khi anh ta không được trao quyền để tạo bất kỳ tên miền cục bộ nào như "localhost.". vì vậy, rfc 1034 cũng không được thiết kế tốt: dường như các tác giả của nó không ngờ rằng có thể nó sẽ không được {biết đến rộng rãi, vì vậy tạo ra vi phạm bảo mật}!

có lẽ rfc 1738 (1994) cuối cùng đã cố gắng đưa ý tưởng phân biệt giữa miền tuyệt đối và tương đối cho nhiều đối tượng và cũng khắc phục vi phạm bảo mật đó sau 6 năm, {nhưng bằng cách sửa lỗi vi phạm bảo mật bằng cách không cho phép các miền tương đối trong url, nó đã khiến các miền tương đối trở nên vô dụng , {nhưng tôi nghĩ có lẽ chúng không được sử dụng rộng rãi, có lẽ chỉ ở một số công ty lớn}}. Vì vậy, điều gì sẽ là [trái] trong kết quả của rfc 1737, nếu nó được tuân theo? - 1) các miền tương đối được khai báo vào năm 1987 cuối cùng sẽ trở nên vô dụng, do đó, dấu chấm, được thiết kế để hiển thị miền tuyệt đối, cuối cùng cũng sẽ trở nên vô dụng và "thừa" về mặt pháp lý, như được định nghĩa bởi các rfcs! (nhưng có lẽ sau đó họ đã lên kế hoạch cho phép lại các tên miền tương đối bằng url sau nhiều năm, khi đối tượng rộng (công chúng nói chung) bắt đầu biết về khả năng của các miền tương đối). 2) và rfc 1737, nếu nó được tuân theo, cũng sẽ sửa lỗi vi phạm an ninh. - nhưng ngay cả rfc 1034 sẽ không tạo ra vi phạm bảo mật nếu nó đạt đến số đông và được hiểu rộng rãi rằng sử dụng tên miền tương đối không an toàn! - vì vậy, công thức chính để khắc phục nó đã tiếp cận được nhiều đối tượng và xuất bản thêm một rfc chỉ là một trong nhiều cách để làm điều đó.

Tôi nghĩ bây giờ có lẽ tính năng miền tương đối đã không được biết đến rộng rãi sau rfc 1034 (năm 1987) vì nó được sử dụng quá hạn chế: chỉ trong một số công ty lớn hoặc mạng cục bộ của nhà cung cấp và đó là một tính năng không có giá trị thực tế, bởi vì các mạng cục bộ đã có thể tạo bất kỳ tên miền cục bộ nào, vì vậy tính năng này chỉ dành cho chính nó, thực tế nó chỉ là một văn bản vô dụng trong rfc mà bất kỳ ai cũng nên biết và sử dụng mà không có bất kỳ lợi ích bổ sung nào! nhưng mọi người đã tạo ra một sự vi phạm bảo mật nhỏ bằng cách bỏ qua rfc, trong khi các trình duyệt bắt đầu tuân theo nó.

tôi đã kiểm tra tính năng tên miền tương đối ngày hôm qua, nó hoạt động. (không sao, vì rfc 2396 (năm 1998) đã cho phép lại sau khi rfc 1034 (năm 1987) bị từ chối, và sau đó rfc 3986 (năm 2005) vẫn cho phép họ). tôi đã thêm hậu tố dns trong windows 10 - bảng điều khiển - ... - thuộc tính thiết bị mạng - thuộc tính ipv4 - bổ sung - tab dns. khi tôi thêm "google.com" thì mở "http: // mail / "trong firefox, nó đã mở máy chủ của google, nhưng nó không được cấu hình để hoạt động chỉ với" mail "trong tiêu đề http" host ", vì vậy tôi có một cái gì đó như trang" 404 ".

-

trả lời của tôi cho văn bản bằng liên kết thứ hai ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

ông cũng trích dẫn quy tắc trong rfc 1738 và nói:

Thật không may, những người thực hiện trình duyệt web của khách hàng dường như không hiểu điều này có nghĩa là gì. Khi bạn truy cập một trang web, giá trị mà hầu hết các trình duyệt web đặt vào trường "Máy chủ:" là những gì người dùng đã nhập, chứ không phải những gì máy tính thực sự sử dụng, sau khi áp dụng danh sách tìm kiếm của người dùng DNS để tạo ra một tên đủ điều kiện từ tên một phần. Ví dụ: đây là ba cách khác nhau mà người dùng có thể tham khảo máy chủ lưu trữ "www.example.com." ... Khi gửi tham số "Máy chủ:" đến máy chủ web, ứng dụng khách trình duyệt web sẽ đặt nội dung người dùng đã nhập ("www.example.com.", "Www.example.com" hoặc "www") về những gì khách hàng cuối cùng thực sự tìm kiếm trong DNS ("www.example.com." trong cả ba trường hợp). ...

- điều này không đúng lắm (chính xác), bởi vì rfc 1738 rất nghiêm ngặt về vấn đề này và nó không cho phép các tên miền tương đối trong tất cả các url, ngay cả khi nó nằm trong thanh địa chỉ của trình duyệt và chính url là cách tạo [khuyến nghị] bất kỳ tài liệu tham khảo nào đến các trang web, ngay cả khi mọi người viết nó trên giấy, do đó người dùng không được phép tham khảo trang web đó theo 3 cách đó, bởi rfc 1738, nếu người dùng đó sẽ nghĩ rằng họ đã sử dụng URL!

và dường như tác giả của văn bản này (Stuart Cheshire) không biết về rfc 2396, vì vậy văn bản này đã lỗi thời.

-

và tình hình hiện nay là gì? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) cho phép tham chiếu đến tên miền tuyệt đối mà không có dấu chấm: nó nói "Nhãn tên miền ngoài cùng bên phải của một tên miền đủ điều kiện trong DNS có thể được theo sau bởi một". "" Và nó nên được sử dụng nếu cần "phân biệt giữa tên miền hoàn chỉnh và một số tên miền cục bộ". Tôi nghĩ rằng do sự kiện nổi bật trên thực tế nên hầu như không bao giờ cần thiết, vì vậy wordpress có thể chấp nhận sự kiện nổi bật trên thực tế và chuyển hướng từ địa chỉ có dấu chấm đến địa chỉ mà không có nó.