จุดที่มี“ www” ใน URL คืออะไร

238

นอกเหนือจากเหตุผลทางประวัติศาสตร์มีเหตุผลที่จะมี "www" ใน URL หรือไม่?

ฉันควรสร้างการเปลี่ยนเส้นทางแบบถาวรจากwww.xyz.comไปยังxyz.comหรือจากxyz.comไปยังwww.xyz.comหรือไม่ คุณจะแนะนำแบบไหนและทำไม

http url redirect

— Quintin Par
แหล่งที่มา

2

ที่เกี่ยวข้อง: stackoverflow.com/questions/1109356/…

— Quintin Par

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

— Fiasco Labs

คำตอบนี้แม้ว่าจะไม่ได้เกี่ยวข้องโดยตรงดูเหมือนเกี่ยวข้อง

— Skippy le Grand Gourou

202

หนึ่งในเหตุผลที่คุณต้องการwwwหรือโดเมนย่อยอื่น ๆ เกี่ยวข้องกับการเล่นโวหาร DNS และระเบียน CNAME

สมมติว่าเพื่อจุดประสงค์ของตัวอย่างนี้ว่าคุณกำลังใช้งานเว็บไซต์ขนาดใหญ่และทำสัญญาการโฮสต์กับ CDN (เครือข่ายการกระจายเนื้อหา) เช่น Akamai โดยทั่วไปสิ่งที่คุณทำคือตั้งค่าระเบียน DNS สำหรับไซต์ของคุณเป็น CNAME ตามที่akamai.comอยู่บางแห่ง สิ่งนี้ทำให้ CDN มีโอกาสในการจัดหาที่อยู่ IP ที่ใกล้กับเบราว์เซอร์ (ในข้อกำหนดทางภูมิศาสตร์หรือเครือข่าย) หากคุณใช้ระเบียน A บนไซต์ของคุณคุณจะไม่สามารถให้ความยืดหยุ่นนี้ได้

สิ่งแปลกประหลาดของ DNS คือถ้าคุณมีระเบียน CNAME สำหรับชื่อโฮสต์คุณจะไม่สามารถมีระเบียนอื่น ๆสำหรับโฮสต์เดียวกันนั้นได้ อย่างไรก็ตามโดเมนระดับบนสุดของคุณexample.comมักจะต้องมีระเบียน NS และ SOA ดังนั้นคุณจะไม่สามารถเพิ่มระเบียน CNAME example.comสำหรับ

การใช้งานwww.example.comจะเปิดโอกาสให้คุณใช้ CNAME สำหรับwwwจุดนั้นไปยัง CDN ของคุณในขณะที่ออกจากระเบียน NS และ SOA ที่example.comต้องการ โดยทั่วไปแล้วexample.comเรกคอร์ดจะมีระเบียน A เพื่อชี้ไปยังโฮสต์ที่จะเปลี่ยนเส้นทางไปwww.example.comใช้การเปลี่ยนเส้นทาง HTTP

— เกร็กฮิวกิล
แหล่งที่มา

3

คุณสามารถระบุระเบียน CNAME "ค่าเริ่มต้น" ที่ชี้ไปที่ CDN คุณไม่จำเป็นต้องใช้ "www" สิ่งนี้ทำให้เซิร์ฟเวอร์ DNS ของคุณมี SOA, NS, CNAME และ RR อื่น ๆ ทั้งหมดสำหรับชื่อโดเมนเดียวกัน

— Chris S

1

ทำไมไม่มีใครพูดถึงALIAS(หรือANAMEบันทึก) ในหัวข้อประเภทนี้ ไม่บรรลุผลเช่นเดียวกับ CNAME ใน nakeddomain (ยกเว้นจากปัญหาคุกกี้ ... )

— Augustin Riedinger

3

@AugustinRiedinger: ระเบียน ANAME ไม่ใช่ประเภท DNS RR มาตรฐาน พวกเขาเป็นกรรมสิทธิ์ของผู้ให้บริการเฉพาะ

— Greg Hewgill

แต่สิ่งนี้สร้างปัญหาความเข้ากันได้หรืออะไรบางอย่าง? มีเหตุผลใดที่เราไม่ควรใช้มัน (นอกเหนือจากการไม่ได้มาตรฐาน แต่เป็นกรรมสิทธิ์)?

— Augustin Riedinger

2

@AugustinRiedinger มันจะไม่ได้รับการสนับสนุนในส่วน DNS เซิร์ฟเวอร์ แต่ถ้าผู้ให้บริการของคุณมีเซิร์ฟเวอร์ DNS ที่รองรับคุณสมบัติเหล่านี้นั่นก็ไม่น่าจะทำให้เกิดปัญหากับลูกค้า

— โคเอ็น

104

หมายเหตุ: จากการให้สัตยาบันและการนำไปใช้ (โดยเบราว์เซอร์ปัจจุบันทั้งหมดยกเว้นMSIE 11 อาจดูความคิดเห็น) ของRFC 6265ในปี 2011 ข้อมูลต่อไปนี้ไม่ถูกต้องอีกต่อไปเนื่องจากคุกกี้จะไม่มีการตั้งค่าข้ามโดเมนย่อย

ในอดีตเหตุผลทางเทคนิคที่ดีอย่างหนึ่งในการสร้างwww.example.comมาตรฐานคือคุกกี้ของโดเมนหลัก (เช่นexample.com) ถูกส่งไปยังโดเมนย่อยทั้งหมด

ดังนั้นหากเว็บไซต์ของคุณใช้คุกกี้พวกเขาจะถูกส่งไปยังโดเมนย่อยทั้งหมด

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

ทางออกที่ดีคือการใช้โดเมนย่อยสำหรับทรัพยากรคงที่เช่นstatic.example.comเพื่อประหยัดแบนด์วิดท์โดยไม่ส่งคุกกี้ ภาพทั้งหมดและการดาวน์โหลดแบบคงที่อื่น ๆ สามารถดาวน์โหลดได้จากที่นั่น ถ้าตอนนี้คุณใช้www.example.comสำหรับเนื้อหาแบบไดนามิกนี้หมายความว่าคุกกี้จะต้องถูกส่งไปไม่ได้ที่จะwww.example.comstatic.example.com

แต่ถ้าexample.comเป็นเว็บไซต์หลักของคุณแล้วคุกกี้จะถูกส่งไปยังทุกstatic.example.comโดเมนย่อยรวมทั้ง

ตอนนี้สิ่งนี้ไม่เกี่ยวข้องกับไซต์ส่วนใหญ่ แต่การเปลี่ยน URL ตามรูปแบบบัญญัติของคุณในภายหลังนั้นไม่ใช่ความคิดที่ดีดังนั้นเมื่อคุณตัดสินexample.comแทนที่จะเป็นwww.*คุณจะติดอยู่กับมัน

อีกทางเลือกหนึ่งคือใช้URL ที่แตกต่างกันโดยสิ้นเชิงสำหรับทรัพยากรคง Stack Overflow สำหรับการใช้งานตัวอย่างsstatic.netYouTube ใช้ytimg.comฯลฯ ...

— คอนราดรูดอล์ฟ
แหล่งที่มา

11

โดยวิธีการที่ฉันไม่ชอบwww.xในฐานะที่เป็นแบบบัญญัติ URL ดังนั้นโดยส่วนตัวฉันอาจจะใช้ URL ที่แตกต่างกันสำหรับทรัพยากรคงที่ถ้าฉันจะออกแบบเว็บไซต์ขนาดใหญ่

— Konrad Rudolph

1

@RobinWinslow แต่การตั้งค่า cookes on domain=example.comจะเป็นการตั้งค่าคุกกี้บนโดเมน apex และใน subdomainsและวิธีการหลีกเลี่ยงปัญหานี้คือการไม่ใช้โดเมน apex สำหรับ HTTP แม้ว่าตกลงกันอีกวิธีหนึ่งก็คือจะไม่ระบุเพียงdomainเมื่อตั้งค่าคุกกี้ ฉันสงสัยว่าสิ่งนี้มีการเปลี่ยนแปลงหรือไม่ตั้งแต่ฉันเขียนคำตอบของฉัน (ซึ่งลงวันที่ก่อนหน้าRFC 6265 ที่เกี่ยวข้อง!) แต่ฉันไม่สามารถค้นหามันได้ในตอนนี้

— Konrad Rudolph

2

ดูเหมือนว่าพฤติกรรมที่ฉันอธิบายเป็นกรณีมาตั้งแต่อย่างน้อย 2011 เมื่อมีการเขียน RFC 6265 (เป็นบทสรุปของพฤติกรรมเบราว์เซอร์ปัจจุบันมากกว่าคำสั่งว่าควรใช้งานอย่างไร) ถึงตอนนี้เราสามารถสรุปได้ว่าเบราว์เซอร์ทั้งหมดจะติดตามมัน ดูstackoverflow.com/questions/1062963/...และbayou.io/draft/cookie.domain.html ด้วยเหตุนี้ฉันคิดว่าคำตอบของคุณทำให้เข้าใจผิดเป็นเวลาอย่างน้อย 7 ปีถึงแม้ว่ามันอาจจะแม่นยำในบางกรณีในขณะที่เขียน คุณช่วยกรุณาอัพเดทเพื่อชี้แจงข้อเท็จจริงนี้ได้ไหม?

— Robin Winslow

2

@RobinWinslow ใช่จะทำ

— Konrad Rudolph

2

หลักฐานเพิ่มเติมที่ IE11 ทำสิ่งที่ไม่ดี: developer.microsoft.com/en-us/microsoft-edge/platform/issues/ …

— Robin Winslow

12

wwwเป็นโดเมนย่อยที่มักจะใช้สำหรับเว็บเซิร์ฟเวอร์ในโดเมนพร้อมกับผู้อื่นเพื่อวัตถุประสงค์อื่น ๆmailเป็นต้นทุกวันนี้กระบวนทัศน์ย่อยไม่จำเป็น หากคุณเชื่อมต่อกับเว็บไซต์ในเบราว์เซอร์คุณจะได้รับเว็บไซต์หรือการส่งอีเมลไปยังเซิร์ฟเวอร์จะใช้บริการอีเมล

การใช้wwwหรือไม่เป็นเรื่องของการตั้งค่าส่วนตัว มุมมองของฝ่ายตรงข้ามสามารถดูได้ที่http://no-www.org/และhttp://www.yes-www.org/ - อย่างไรก็ตามฉันเชื่อว่าwwwไม่จำเป็นและเพิ่ม cruft เพิ่มเติมให้กับ URI

เซิร์ฟเวอร์ส่วนใหญ่ส่งเว็บไซต์เดียวกันด้วยวิธีใดวิธีหนึ่ง แต่ไม่เปลี่ยนเส้นทาง สำหรับวัตถุประสงค์ SEO ให้เลือกหนึ่งรายการจากนั้นรับส่วนอื่น ๆ เพื่อเปลี่ยนเส้นทาง ตัวอย่างเช่นโค้ด PHP บางตัวในการทำเช่นนี้:

if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
  header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
  exit;
}

อย่างไรก็ตามเหตุผลบางประการที่ส่งเสริมการใช้wwwโดเมนย่อยที่ทำโดยผู้ตอบอื่น ๆ ก็ดีเช่นกันเช่นไม่ส่งคุกกี้ไปยังเซิร์ฟเวอร์คงที่ (เครดิตKonrad Rudolph )

— Delan Azabani
แหล่งที่มา

2

ดูเหมือนว่าno-www.orgจะเปลี่ยนกลับไปใช้หน้าเพจ parked for sale ที่ซึ่งyes-www.orgยังคงแข็งแกร่งอยู่ ฉันเดาว่าจะจัดการ ทุกคนใช้ "www" นับจากนี้เป็นต้นไป

— nunya

9

มันค่อนข้างประวัติศาสตร์ กาลครั้งหนึ่งเราเคยมี www.example.com, ftp.example.com, images.example.com, uk.example.com ฯลฯ ซึ่งดูเหมือนจะเป็นสิ่งที่สมเหตุสมผลที่ต้องทำและให้วิธีง่ายๆในการกระจายโหลดระหว่าง เซิร์ฟเวอร์

วันนี้ฉันจะไปเพื่อ example.com สำหรับเว็บไซต์หลักและเปลี่ยนเส้นทางรุ่น www ไปที่

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

ดูเพิ่มเติมที่:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to- www หรือไม่ต่อการ www

— ชุมชน
แหล่งที่มา

8

หากคุณจะมีโดเมนย่อยเพื่อวัตถุประสงค์อื่น (เช่นบล็อก) คุณอาจต้องการแยกความแตกต่างของไซต์และมีwwwคำนำหน้าสำหรับไซต์ปกติ นอกเหนือจากนั้นสิ่งสำคัญเพียงอย่างเดียวคือเลือกหนึ่งในสองและติดกับมัน (ด้วยเหตุผล SEO)

— Oded
แหล่งที่มา

1

ฉันไม่สามารถหาข้อมูลอ้างอิงได้ในขณะนี้ แต่อาจมีผลต่อนโยบายต้นทางเดียวกัน

— Kobi

ใช่มันจะน่าเสียดาย คุณไม่สามารถ AJAX www.example.comจากexample.comหรือในทางกลับกันหากไม่มีอะไรอย่าง JSONP

— Delan Azabani

7

ฉันจะทำก่อน การwwwประชุมดังกล่าวมาจากยุคแรก ๆ ของ HTTP ที่ www.cmu.edu และ cmu.edu เป็นเครื่องที่แตกต่างกันมาก

— ขยะ
แหล่งที่มา

10

ใน 'วันแรก ๆ ' คุณจะไม่ค่อยเห็นระเบียน A สำหรับโดเมน - บางทีอาจเป็นระเบียน MX แต่คุณไม่ค่อยมีโฮสต์ที่นั่น

— Joe H.

2

นี่เป็นอีกมุมมองหนึ่ง

โดยไม่มี www มีข้อเสียเล็กน้อยเมื่อมันมาถึงสื่อที่เป็นข้อความไม่ว่าจะพิมพ์หรือออนไลน์และที่ได้รับการยอมรับว่าเป็นที่อยู่เว็บ โดยปกติแล้วในการพิมพ์จะเห็นได้ชัดว่า example.com เป็นที่อยู่เว็บและคุณสามารถเพิ่มการจัดแต่งทรงผมเพื่อเน้นที่ แต่ข้อความธรรมดาออนไลน์ ไม่ใช่เรื่องง่าย โอกาสที่ว่าถ้าคุณส่งข้อความธรรมดาไม่ว่าจะเป็นอีเมล, ทวีต, โพสต์ใน Facebook, SMS หรืออะไรก็ตามมันจะจดจำ URL ที่ขึ้นต้นด้วย http: // หรือ www แต่จะไม่รับรู้หากไม่มีอย่างใดอย่างหนึ่ง ดังนั้นในการสร้าง URL ให้เป็นลิงค์ที่คลิกได้คุณต้องใส่ www หรือ http: // ที่ด้านหน้าและสอง www สั้นกว่า clunky น้อยกว่าในการอ่านและอ่านง่ายขึ้น

— รังสี
แหล่งที่มา

2

http://example.com/มีคุณสมบัติครบถ้วนในขณะที่www.example.comไม่มี ฉันชอบวิธีการที่มีคุณสมบัติครบถ้วนเพราะมันเป็นเสมอที่รู้จักเป็น URL ไม่คำนึงถึงไม่ว่าจะเป็นhttps://example.uk/หรือhttps://blog.example.eu/หรืออะไรก็ตาม มันสอดคล้องกับการระบุโปรโตคอลของเว็บไซต์ที่ปลอดภัยเป็น HTTPS; www.example.comเป็นเพียงโดเมนและไม่ได้บอกว่าควรใช้โปรโตคอลใดในการเข้าถึง

— James Haigh