เว็บไซต์ควรจัดการกับชื่อโฮสต์ด้วยจุดต่อท้ายอย่างไร

ฉันอ่านคำถามนี้URL จะมีจุดได้อย่างไร ในตอนท้ายเช่น www.bla.de และตระหนักว่า FQDN ควรมีส่วนท้าย.สำหรับรูตเลเบลของทรี DNS:

example.com. แทน example.com

อย่างไรก็ตามมีปัญหาตามที่ระบุไว้ในบทความบล็อกนี้ :

หากคุณไม่พิจารณาข้อเท็จจริงที่ว่าผู้ใช้สามารถป้อนชื่อโดเมนด้วยจุดท้ายได้โดยไม่ตั้งใจหรือไปตามลิงก์ที่ได้รับจาก "well-wisher" และรับชื่อโดเมนของคุณด้วยจุดที่จุดสิ้นสุดเช่น ผลอาจนำไปสู่ผลที่ไม่คาดคิด:

1) หากเว็บไซต์ใช้ HTTPS เมื่อนำทางไปยังชื่อโดเมนด้วยจุดท้ายเบราว์เซอร์จะแสดงคำเตือนเกี่ยวกับการเชื่อมต่อที่ไม่น่าเชื่อถือ

2) การตรวจสอบความถูกต้องอาจใช้งานไม่ได้เนื่องจากคุกกี้มักจะถูกตั้งค่าสำหรับชื่อโดเมนโดยไม่มีจุดสิ้นสุด ผู้ใช้ในกรณีนี้จะประหลาดใจมากว่าทำไมเขาไม่สามารถเข้าสู่ระบบได้เป็นที่น่าสังเกตว่าถ้าคุณตั้งค่าคุกกี้สำหรับชื่อโดเมนที่มีจุดเป็นจุดสิ้นสุดคุกกี้นี้จะไม่ถูกส่งต่อไปยังชื่อโดเมนโดยไม่มีจุด ในตอนท้ายและในทางกลับกัน

3) จาวาสคริปต์ในหน้าอาจใช้งานไม่ได้

4) อาจมีปัญหากับการแคชของหน้าเว็บไซต์ (ตัวอย่างเช่นhttps://www.cloudflare.com/ไม่ล้างแคชหน้าหากชื่อโดเมนมีจุดท้ายที่พิจารณาว่าเป็นชื่อโดเมนที่ไม่ถูกต้อง)

5) หากอยู่ในเงื่อนไขในการกำหนดค่าเว็บเซิร์ฟเวอร์คุณต้องพึ่งพาชื่อโดเมนเฉพาะ ($ http_host ใน Nginx,% {HTTP_HOST} ใน Apache) โดยไม่มีจุดสิ้นสุดคุณอาจเผชิญกับสถานการณ์ที่ไม่คาดคิดมากมาย: การเปลี่ยนเส้นทางที่ไม่คาดคิดขั้นพื้นฐาน - ปัญหาการอนุญาต ฯลฯ

6) หากเว็บเซิร์ฟเวอร์ไม่ได้รับการกำหนดค่าให้รับคำขอในชื่อโดเมนด้วยจุดต่อท้ายผู้ใช้ที่พิมพ์ชื่อโดเมนด้วยจุดต่อท้ายโดยไม่ตั้งใจจะเห็นสิ่งที่ต้องการไม่ถูกต้อง - ชื่อโฮสต์ไม่ถูกต้อง

7) เป็นไปได้ที่เสิร์ชเอ็นจิ้นอาจพบว่าทรัพยากรของคุณมีเนื้อหาที่ซ้ำกันหากมีคนตั้งใจหรือโพสต์ลิงก์ไปยังหน้าเว็บของคุณโดยมีจุดที่ท้ายชื่อโดเมน

ฉันยังตระหนักว่าhttp://webmasters.stackexchange.com./ทำ400 Bad Requestไม่แต่เนื่องจากชื่อโดเมนที่เหมาะสมควรมี.ที่ส่วนท้ายเราไม่ควรออก400ข้อผิดพลาดหรือ301เปลี่ยนเส้นทางสำหรับชื่อโฮสต์ที่ไม่มีจุดต่อท้ายใช่หรือไม่ อะไรคือวิธีที่เหมาะสมในการจัดการกับปัญหานี้ในลักษณะที่สอดคล้องและสอดคล้องกัน?

ในการตอบคำถามของคุณบางส่วนคุณสามารถเพิ่มในกฎการส่งต่อผู้ที่ยอมรับมาตรฐานของ htaccess ได้ ในแง่พื้นฐานของ HTTP มันจะมองหาช่วงเวลาก่อนที่ URI และทำงานเป็นกลไกการส่งต่อที่ไม่ซ้ำกันที่คุณใช้ นี่คือตัวอย่างรวมถึงเส้นทางย่อย "addon domain" ทั่วไป:

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]

สิ่งนี้จะทำคือส่งต่อสิ่งต่อไปนี้ทั้งหมดไปยังโดเมน wwwical HTTP wwwicalical:

• 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) นี่เป็นเพราะมันเห็น SSL "โฮสต์" ในกรณีการใช้งานหลัง TLD ฉันไม่แน่ใจว่าวิธีแก้ปัญหาที่จะจัดการกับคำเตือน SSL โฮสต์เพราะมันมาก่อน htaccess และสิ่งต่าง ๆ

ฉันชอบคิดว่าจุดท้ายสุดเป็นราก "ของจริง" ของอินเทอร์เน็ตและมันอาศัยอยู่ในเวอร์จิเนียสหรัฐอเมริกา หากคุณไม่ใส่จุดออกไปแสดงว่ารูตบางอันมีความหมายอยู่เสมอ สำหรับผู้ใช้ทั่วไปมันเป็นรูทเดียวกันและนั่นเป็นสถานการณ์ที่ฉันจะพูดคุยวันนี้

ในทางที่ผิดของฉันฉันพบว่าจุดที่มีประโยชน์ต่อท้ายค่อนข้างมีประโยชน์ หากฉันกำลังตรวจสอบเว็บไซต์ของคนอื่นและฉันต้องการเริ่มต้นใหม่โดยไม่มีแคชไม่มีคุกกี้ ฯลฯ และฉันขี้เกียจเกินกว่าที่จะล้างข้อมูลออกฉันจะใช้เบราว์เซอร์อื่นหรือฉันจะเพิ่มจุด หากไซต์ไม่เปลี่ยนเส้นทางฉันแสดงว่าฉันมี 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");
    }   

ความคิดเห็นของฉันที่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 (Common Internet Scheme) URL นั้นเป็นชื่อโดเมนที่ผ่านการรับรองโดยสมบูรณ์และกลไกแบบดั้งเดิมสำหรับการจำแนกชื่อโดเมนที่ผ่านการรับรองโดยสมบูรณ์ - ชื่อโดเมนที่ผ่านการรับรองไม่ได้ใช้ ไม่ว่าจะเป็น example.com หรือ example.com โฮสต์นั้นตั้งใจจะเหมือนกัน

- ฉันคิดว่าเขาไม่ถูกต้องฉันคิดว่า "example.com" ไม่ได้รับอนุญาตใน URL ตาม rfc 1738 ทั้งหมดถูกอ้างถึงในข้อความที่สองและฉันอ้างว่า:

3.1 ไวยากรณ์ของโครงการอินเทอร์เน็ตทั่วไป
        // <user>: <รหัสผ่าน> @ <โฮสต์>: <port> / <url เส้นทาง>
    เจ้าภาพ
        ชื่อโดเมนแบบเต็มของโฮสต์เครือข่าย

และ "example.com" ไม่สามารถใช้ในส่วนหัว http ได้ในขณะนั้นเนื่องจาก rfc 1738 เป็นของปี 1994 และฟิลด์โฮสต์ปรากฏเฉพาะกับ http 1.1 ในปี 1997 (คุณสามารถเช็คอินวิกิพีเดีย)

ดังนั้นมีเพียง fqdn เท่านั้นที่ได้รับอนุญาตใน URL ฉันคิดว่านี่เป็นข้อผิดพลาดใน rfc 1738 เพราะด้วยวิธีดังกล่าวทำให้ ("พยายามสร้าง)" คุณสมบัติโดเมนที่เกี่ยวข้อง "ไม่มีประโยชน์ หากไม่ได้ไม่อนุญาตก็สามารถใช้แท็ก "a" แท็ก hrefs ในไซต์สคริปต์ท้องถิ่นหรือเอกสาร html แบบคงที่ใน บริษัท ใหญ่ที่ใช้โดเมนญาติหากเบราว์เซอร์และเซิร์ฟเวอร์สนับสนุน แต่ถึงแม้ว่า rfc 1738 ไม่อนุญาตพวกเขาคนก็ไม่เชื่อฟังพวกเขายังคงใช้โดเมนระดับบนสุดในรูปแบบที่สัมพันธ์กันโดยไม่มีจุดต่อท้ายดังนั้นการอนุญาตโดย rfc 1738 จึงไม่ใช่ปัญหาในทางปฏิบัติขนาดใหญ่และผู้คนก็ใช้ทางเลือกอื่น ไปยังโดเมนที่เกี่ยวข้อง: พวกเขาเพิ่งสร้างโดเมนระดับบนสุดในท้องถิ่นเช่น "localhost" (และใช้และใช้งานได้โดยไม่ต้องมีจุดต่อท้าย)

จากนั้นเขาก็พูดว่า:

น่าเสียดายที่ในทางปฏิบัติเว็บเบราว์เซอร์มักจะละเมิดข้อกำหนดนั้นและส่งผ่านส่วน "โฮสต์" ผ่านขั้นตอนการรับรองชื่อของไลบรารีไคลเอ็นต์ DNS ของพวกเขาเมื่อทำการแมปชื่อโฮสต์กับชุดที่อยู่ IP (ตัวอย่างเช่นผู้ที่ใช้ไลบรารีไคลเอนต์ BIND DNS จะออกจากชุดตัวเลือก RES_DNSRCH และจะไม่ผนวกจุดต่อท้ายสุดท้ายหากไม่มีอยู่)

- ฉันคิดว่าเขาหมายความว่าโฮสต์ที่ไม่มีจุดต่อท้ายควรถูกโยนออกไปเนื่องจากข้อผิดพลาดและควรส่งผ่านเฉพาะโดเมนแบบสัมบูรณ์ (fqdn) ไปยัง dns ฉันคิดว่าเบราว์เซอร์อาจส่งผ่านโดเมนทั้งหมดไปยัง DNS เพราะผู้คนใช้โดเมนระดับบนสุดที่กำหนดเองเช่น "localhost" และต่อมาใน rfc 2396 เผยแพร่ในปี 1998 อนุญาตให้ใช้โดเมนระดับบนสุดใน URL ที่ไม่มีจุดต่อท้ายได้

จากนั้นผู้เขียน (Jonathan de Boyne Pollard) อ้างถึง rfc 2396 และเสียใจเกี่ยวกับมันเปลี่ยนไปตามพฤติกรรมของมนุษย์ที่จัดตั้งขึ้นเช่นพฤตินัย standarts กล่าวว่าจะดีกว่าถ้าเบราว์เซอร์เชื่อฟัง rfc 1738 และแนะนำให้ทุกคนใช้ fqdn เท่านั้นใน ทุกสถานที่ตามที่ได้รับคำสั่งจาก rfc 2281

- แต่จะเกิดอะไรขึ้นหากผู้คนเชื่อฟัง rfc 1738? URL เช่น "http://example.com/test.html "และ"http: //localhost/test.html "ทั้งหมดต้องถูกเขียนใหม่เป็น"http://example.com./test.html "และ"http://localhost./test.html". เบราว์เซอร์จะต้องทำเครื่องหมายโฮสต์โดยไม่มีจุดเป็นข้อผิดพลาดหรือเปลี่ยนเส้นทางเมื่อคลิกไปยังรูปแบบเต็ม / สัมบูรณ์ของพวกเขาทุกคนที่กำหนดค่าโดเมนระดับบนสุดในท้องถิ่นเช่น" localhost "จะต้องกำหนดค่าเซิร์ฟเวอร์ให้ยอมรับเฉพาะคำขอ สำหรับโดเมนเช่น "localhost" หรือยอมรับและเปลี่ยนเส้นทาง [urls ทั้งหมดภายใน] "localhost" เป็น [url ที่เกี่ยวข้องใน] "localhost." ข้อความเช่น "localhost" จะมีประโยชน์เฉพาะเมื่อพิมพ์ในแถบที่อยู่ของเบราว์เซอร์ จะเป็นการใช้งานที่ไร้ประโยชน์เพียงอย่างเดียวและไม่จำเป็นต้องใช้คุณสมบัติโดเมนสัมพัทธ์เพราะเบราว์เซอร์ค้นหาโดเมนในการพิมพ์การใช้งานในแหล่ง html จะกลายเป็นไร้ประโยชน์เพราะจะนำไปสู่การเชื่อมโยงดังกล่าวจะไม่ทำงานหรือคลิกทั้งหมด ลิงก์กับ "localhost" จะย้ายผู้ใช้ไปที่ "localhost"และมันจะเป็นเพียงการเปลี่ยนเส้นทางพิเศษในทุกคลิก (บนลิงก์ดังกล่าว) ดังนั้น rfc 1738 จะทำให้คุณสมบัติ" โดเมนญาติ "ที่วางแผนไว้นั้นไร้ประโยชน์โดยสิ้นเชิงหาก บริษัท บางแห่งใช้คุณลักษณะดังกล่าวและใช้โดเมนที่สัมพันธ์กันในเว็บไซต์ท้องถิ่นของตน และ URL ที่มีโดเมนสัมพัทธ์จะไม่ถูกเปลี่ยนเส้นทางไปยังแบบฟอร์มที่สมบูรณ์โดยเบราว์เซอร์ดังนั้นไซต์ของพวกเขาจึงทำงานตามปกติหากพวกเขาเชื่อฟัง rfc 2279 พวกเขาจะกำหนดค่าเซิร์ฟเวอร์ให้ยอมรับเฉพาะ fqdn และพวกเขาจะต้องเขียน URL fqdn หรือทำงานกับการเปลี่ยนเส้นทางพิเศษทุกครั้งที่มีการคลิก URL ดังกล่าวหาก บริษัท ที่ชอบมีโดเมนแบบสั้นเช่น "team101" แทน "team101.microsoft.com" ในแถบที่อยู่และแหล่ง html พวกเขาจะต้องเริ่มใช้งาน โดเมนระดับบนสุดภายในที่กำหนดเองเช่น "team101" เช่น like "localhost "แทนที่จะเป็นโดเมนย่อยเช่น" team101.microsoft.com "(ซึ่งสามารถใช้เป็นเพียงแค่" team101 "ก่อนที่พวกเขาจะเชื่อฟัง rfc 1738)

-

และฉันได้พบว่าจุดต่อท้ายซึ่งได้รับการสนับสนุนอย่างมากจาก rfc 1738 นั้นปรากฏขึ้นจริง ๆ หลังรูปแบบที่ไม่มีจุดต่อท้าย! มันปรากฏตัวด้วย rfc 1034 ในปี 1987 มันถูกอ้างถึงในลิงค์ที่สองและฉันอ้างว่า:

เนื่องจากชื่อโดเมนที่สมบูรณ์นั้นลงท้ายด้วยป้ายกำกับของรูท
แบบฟอร์มที่พิมพ์ซึ่งลงท้ายด้วยจุด เราใช้คุณสมบัตินี้เพื่อแยกความแตกต่างระหว่าง:
- สตริงอักขระซึ่งแสดงถึงชื่อโดเมนที่สมบูรณ์
 (มักเรียกว่า "แน่นอน") ตัวอย่างเช่น "poneria.ISI.EDU"
- สตริงอักขระที่แสดงถึงป้ายกำกับเริ่มต้นของ
 ชื่อโดเมนที่ไม่สมบูรณ์และควรจะเสร็จสิ้นภายใน
 ซอฟต์แวร์ท้องถิ่นโดยใช้ความรู้เกี่ยวกับโดเมนท้องถิ่น (บ่อยครั้ง
 เรียกว่า "ญาติ") ตัวอย่างเช่น "poneria" ที่ใช้ใน
 โดเมน ISI.EDU

rfc 1034 (ของ 1987) เพิ่งประกาศโดเมนทั้งหมดที่ใช้ดูเหมือนว่าพวกเขาทั้งหมดไม่มีจุดต่อท้ายประกาศพวกเขาทั้งหมดเป็นโดเมนญาติ! แต่พวกเขายังคงทำงานเหมือนเดิมดังนั้นอาจมีเพียงไม่กี่คนที่รู้เกี่ยวกับสิ่งนั้นและยังคงคิดว่าพวกเขาร้องขอไซต์ "example.com" ที่ไม่เหมือนใครอย่างแท้จริงเมื่อพวกเขาใช้ "example.com" โดยไม่มีจุดต่อท้าย ดังนั้นจึงกลายเป็นการละเมิดความปลอดภัยเพิ่มเติมในบางกรณี: example.com ชื่อจริงอาจถูกปลอมแปลงโดยผู้ดูแลระบบย่อยแม้ว่าเขาจะไม่ได้รับสิทธิ์ในการสร้างโดเมนท้องถิ่นเช่น "localhost" ดังนั้น rfc 1034 ก็ไม่ได้ออกแบบมาอย่างดีมาก: ดูเหมือนว่าผู้เขียนไม่คาดหวังว่ามันอาจจะเป็น {ไม่เป็นที่รู้จักอย่างกว้างขวางดังนั้นการสร้างการละเมิดความปลอดภัย}!

อาจเป็น rfc 1738 (1994) ในที่สุดก็พยายามที่จะนำความคิดของความแตกต่างระหว่างโดเมนสัมบูรณ์และญาติให้กับผู้ชมที่กว้างและยังแก้ไขการละเมิดความปลอดภัยหลังจาก 6 ปี {แต่ด้วยการแก้ไขการละเมิดความปลอดภัยโดยไม่อนุญาตโดเมนญาติใน URL {แต่ฉันคิดว่าพวกเขาอาจไม่ได้ใช้กันอย่างแพร่หลายอาจจะมีเฉพาะใน บริษัท ใหญ่บางแห่ง}} ดังนั้นสิ่งที่จะ [เหลือ] อันเป็นผลมาจาก rfc 1737 ถ้ามันจะเชื่อฟัง? - 1) โดเมนสัมพัทธ์ที่ประกาศในปี 1987 จะกลายเป็นสิ่งที่ไร้ประโยชน์ในที่สุดดังนั้นจุดต่อท้ายถูกออกแบบมาเพื่อแสดงโดเมนแบบสัมบูรณ์และในที่สุดก็จะกลายเป็นไร้ประโยชน์ในที่สุด (แต่บางทีพวกเขาวางแผนในภายหลังอนุญาตโดเมนญาติใน URL หลังจากหลายปีเมื่อผู้ชม (ประชาชนทั่วไป) เริ่มรู้เกี่ยวกับความเป็นไปได้ของโดเมนญาติ) 2) และ rfc 1737 หากปฏิบัติตามก็จะแก้ไขการละเมิดความปลอดภัยด้วย - แต่แม้กระทั่ง rfc 1034 จะไม่สร้างการละเมิดความปลอดภัยหากถึงมวลชนและเป็นที่เข้าใจกันอย่างกว้างขวางว่าการใช้โดเมนญาตินั้นไม่ปลอดภัย! - ดังนั้นสูตรหลักในการแก้ไขคือการเข้าถึงผู้ชมจำนวนมากและการเผยแพร่อีกหนึ่ง rfc เป็นเพียงหนึ่งในหลายวิธีที่จะทำ

ฉันคิดว่าตอนนี้อาจเป็นไปได้ว่าคุณสมบัติโดเมนสัมพัทธ์ยังไม่เป็นที่รู้จักอย่างแพร่หลายหลังจาก rfc 1034 (ของปี 1987) เพราะมันมีการใช้งานที่ จำกัด เกินไป: เฉพาะใน บริษัท ใหญ่หรือเครือข่ายท้องถิ่นของผู้ให้บริการ เนื่องจากเครือข่ายท้องถิ่นสามารถสร้างโดเมนท้องถิ่นใด ๆ ได้ดังนั้นคุณลักษณะนี้จึงเป็นของตัวเองจริงๆแล้วมันเป็นเพียงข้อความไร้ประโยชน์ใน rfc ที่ทุกคนควรรู้และใช้โดยไม่ได้รับผลประโยชน์เพิ่มเติม! แต่ผู้คนสร้างการละเมิดความปลอดภัยเล็ก ๆ น้อย ๆ โดยการละเลย rfc อย่างกว้างขวางในขณะที่เบราว์เซอร์เริ่มเชื่อฟัง

ฉันตรวจสอบคุณสมบัติโดเมนที่เกี่ยวข้องเมื่อวานนี้มันใช้งานได้ (มันก็โอเคเพราะ rfc 2396 (จากปี 1998) ได้รับอนุญาตอีกครั้งหลังจากที่ rfc 1034 (จากปี 1987) ถูกปฏิเสธและในภายหลัง rfc 3986 (จากปี 2005) ยังคงอนุญาตให้ใช้ได้) ฉันเพิ่มคำต่อท้าย DNS ใน windows 10 - แผงควบคุม - ... - คุณสมบัติของอุปกรณ์เครือข่าย - คุณสมบัติ ipv4 - เพิ่มเติม - แท็บ dns เมื่อฉันเพิ่ม "google.com" แล้วเปิด "http: // mail / "ใน firefox มันเปิดเซิร์ฟเวอร์ของ google แต่ไม่ได้กำหนดค่าให้ทำงานกับ" mail "ในส่วนหัว" host "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 ก็เป็นวิธีที่แนะนำ [ในการสร้าง] การอ้างอิงไปยังไซต์ใด ๆ แม้ว่าผู้ใช้จะเขียนลงบนกระดาษดังนั้นผู้ใช้จึงไม่สามารถอ้างถึงไซต์นั้นใน 3 วิธีโดย rfc 1738 หากผู้ใช้นั้นคิดว่าพวกเขาใช้ URL!

และดูเหมือนว่าผู้เขียนข้อความนี้ (Stuart Cheshire) ไม่รู้เกี่ยวกับ rfc 2396 ดังนั้นข้อความนี้ล้าสมัย

-

และสถานการณ์ในปัจจุบันเป็นอย่างไร rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) อนุญาตให้อ้างถึงโดเมนแบบสัมบูรณ์โดยไม่ต้องมีจุดต่อท้าย: มันบอกว่า "ฉลากโดเมนที่ถูกต้องที่สุดของชื่อโดเมนที่ผ่านการรับรองครบถ้วนใน DNS อาจตามมาด้วยชื่อเดียว" "" และควรใช้หากจำเป็น "เพื่อแยกความแตกต่างระหว่างชื่อโดเมนที่สมบูรณ์และโดเมนท้องถิ่นบางตัว" ฉันคิดว่าเนื่องจาก de facto standarts แทบจะไม่จำเป็นเลยดังนั้น wordpress สามารถยอมรับรูปแบบ de facto และเปลี่ยนเส้นทางจากที่อยู่ด้วยจุดต่อท้ายไปยังที่อยู่โดยที่ไม่มี