ฉันสามารถเปลี่ยนลิงค์ http: // ทั้งหมดเป็นเพียง // ได้ไหม

240

Dave Wardพูดว่า

มันไม่ได้เป็นการอ่านที่เบานัก แต่ส่วนที่ 4.2 ของ RFC 3986มีให้สำหรับ URL ที่ผ่านการรับรองโดยสมบูรณ์ซึ่งไม่ใช้โปรโตคอล (HTTP หรือ HTTPS) ทั้งหมด เมื่อละเว้นโปรโตคอลของ URL เบราว์เซอร์จะใช้โปรโตคอลของเอกสารอ้างอิงแทน

กล่าวง่ายๆว่า "ไม่ใช้โปรโตคอล" URL เหล่านี้อนุญาตให้มีการอ้างอิงเช่นนี้ในเบราว์เซอร์ทุกตัวที่คุณจะลองใช้:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

ในตอนแรกมันดูแปลก ๆ แต่ URL“ ไม่ใช้โปรโตคอล” นี้เป็นวิธีที่ดีที่สุดในการอ้างอิงเนื้อหาบุคคลที่สามที่มีให้ผ่านทั้ง HTTP และ HTTPS

สิ่งนี้จะช่วยแก้ไขข้อผิดพลาดเนื้อหาแบบผสมที่เราเห็นในหน้า HTTP โดยสมมติว่าสินทรัพย์ของเรามีให้บริการผ่านทั้ง HTTP และ HTTPS

นี่เป็นเบราว์เซอร์ที่เข้ากันได้อย่างสมบูรณ์หรือไม่? มีข้อแม้อื่น ๆ อีกไหม?

— คนจ่ายเงิน
แหล่งที่มา

ฉันอ่านเกี่ยวกับเทคนิคนี้ที่ IE บล็อกเมื่อไม่นานมานี้ แต่เมื่อฉันลองมันก็ไม่ได้ผลดีนัก หากไซต์ของฉันแสดงผลด้วย HTTPS เบราว์เซอร์ (Chrome) ยังคงใช้ HTTP สำหรับ URL ที่ไม่มีโปรโตคอล

— Christopher Ramírez

10

คำเตือน: อย่าลืมห้ามใช้ URIs แบบไร้ผู้ใช้ในการเปลี่ยนเส้นทาง HTTP 3xx !! ส่วนหัว HTTP เข้ากันไม่ได้กับรูปแบบ URL นี้ หากคุณต้องการเปลี่ยนเส้นทางขึ้นอยู่กับแบบแผนให้ใช้ mod_rewrite หรือคล้ายกัน

— user2596282

1

@ user2596282 การทดลองใน Chrome และ Firefox เวอร์ชันใหม่ไม่เห็นด้วยกับคุณเช่นเดียวกับการแก้ไข (ยังอยู่ในร่าง) เป็น HTTP 1.1 ข้อมูลจำเพาะที่กำหนดโดยคณะทำงาน HTTPbis (ดูsvn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/ เป็นต้น ) บางทีสิ่งที่คุณพูดอาจเป็นความจริงสำหรับเบราว์เซอร์บางตัว คุณรู้จักโดยเฉพาะอย่างยิ่งที่ล้มเหลวใน URL ที่เกี่ยวข้องกับโปรโตคอลในส่วนหัวสถานที่ตั้ง?

— Mark Amery

คำถามเดียวกันกับคำตอบที่ดี: URL แบบสัมบูรณ์ละเว้นโพรโทคอล (โครงร่าง) เพื่อรักษาหนึ่งในหน้าปัจจุบัน

— ÁlvaroGonzález

อย่าใช้พวกเขาพวกเขาน่าเกลียดและซ้ำซ้อน

— IllidanS4 ต้องการโมนิก้ากลับ

204

ฉันทดสอบอย่างละเอียดก่อนเผยแพร่ เบราว์เซอร์ที่มีอยู่ทั้งหมดในการทดสอบกับบนBrowsershotsผมจะสามารถหาคนที่ไม่ได้จัดการโปรโตคอล URL ที่เกี่ยวข้องได้อย่างถูกต้อง: เบราว์เซอร์ปิดบัง * ระวังเรียกว่าDillo

มีข้อเสียสองประการที่ฉันได้รับข้อเสนอแนะเกี่ยวกับ:

URL ที่ไม่ใช้โปรโตคอลในการทำงานอาจไม่ทำงานอย่างที่คาดไว้เมื่อคุณ "เปิด" ไฟล์โลคัลในเบราว์เซอร์ของคุณเนื่องจากโปรโตคอลหลักของหน้าจะเป็นไฟล์: /// โดยเฉพาะอย่างยิ่งเมื่อคุณใช้ URL ที่ไม่ใช้โปรโตคอลสำหรับทรัพยากรภายนอกเช่นเนื้อหาที่โฮสต์โดย CDN การใช้เว็บเซิร์ฟเวอร์ในพื้นที่เช่น Apache หรือ IIS เพื่อทดสอบกับที่อยู่http: // localhost นั้นใช้งานได้ดี
เห็นได้ชัดว่ามีแอปตัวอ่านฟีดของ iPhone อย่างน้อยหนึ่งตัวที่จัดการ URL ที่ไม่ได้ใช้โปรโตคอลอย่างถูกต้อง ฉันไม่ทราบว่ามีปัญหาหรือความนิยม สำหรับการโฮสต์ไฟล์ JavaScript นั้นไม่ใช่ปัญหาใหญ่นักเนื่องจากผู้อ่าน RSS มักจะมองข้ามเนื้อหา JavaScript อยู่ดี อย่างไรก็ตามอาจเป็นปัญหาหากคุณใช้ URL เหล่านี้สำหรับสื่อเช่นภาพภายในเนื้อหาที่ต้องมีการเผยแพร่ผ่าน RSS (แม้ว่าแอปตัวอ่านเดียวนี้บนแพลตฟอร์มเดียวอาจมีบัญชีสำหรับผู้อ่านจำนวนเล็กน้อย)

— Dave Ward
แหล่งที่มา

33

ในขณะที่ 7/8 จับ URL ที่โปรโตคอล (aka. ยูริ schemeless) ได้ดีในกรณีส่วนใหญ่เมื่อสไตล์ชีตที่ระบุไว้ที่มี URL ดังกล่าวก็จะดาวน์โหลดพวกเขาเป็นครั้งที่สอง (ดังนั้นSteve Soudersพูด)

— lucasrizoli

3

ฉันพบว่า IE6 พยายามแปลง URI ให้เป็นแบบสัมพัทธ์ (เช่นการลบเครื่องหมายทับชั้นนำ) นี่คือlinkองค์ประกอบ ตัวอย่างเช่นเมื่อระบุ//fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 http://mysite.com/fonts.googleapis.com/css/<...>พยายามที่จะโหลด ไม่ค่อยดี!

— CBono

2

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

— Kzqai

3

ฉันเห็นสิ่งนั้นมากมายในบันทึกของฉันซึ่งไม่เกี่ยวข้องกับ URL ที่ไม่ใช้โปรโตคอล แมงมุมจำนวนมากนั้นเขียนได้ไม่ดีนักอย่างไม่น่าเชื่อ

— Dave Ward

11

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

— ซิงโคร

37

คำถามที่ว่าใครสามารถเปลี่ยนการเชื่อมโยงของพวกเขาทั้งหมดให้สัมพันธ์กับโพรโทคอลอาจถูกพิจารณาโดยพิจารณาคำถามว่าควรจะทำเช่นนั้นหรือไม่ อ้างอิงจากพอลไอริช :

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

— Ohad Schneider
แหล่งที่มา

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

— joonas.fi

1

@ joonas.fi สิ่งเดียวที่ฉันนึกได้คือการหลีกเลี่ยงคำเตือน HTTP / HTTPS แบบผสมที่อาจถูกสร้างขึ้นโดยเบราว์เซอร์บางตัว

— Ohad Schneider

3

@Ohad_Schneider คำเตือนจะถูกเรียกใช้เฉพาะในกรณีที่เอกสารถูกโหลดผ่านการรักษาความปลอดภัย (https) แต่สินทรัพย์มากกว่าที่ไม่ปลอดภัย (http) สิ่งที่ฉันแนะนำคือคุณสามารถโหลดสินทรัพย์ในที่ปลอดภัยได้ตลอดเวลาแม้ว่าเอกสารนั้นจะถูกโหลดไปที่ไม่ปลอดภัย ไม่มีคำเตือนและไม่มีเหตุผลที่จะไม่ใช้ระบบความปลอดภัยโดยไม่จำเป็นต้องมี

— joonas.fi

1

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

— joonas.fi

@ joonas.fi Wut เหรอ? O_o หากใครบางคนมีเว็บไซต์ HTTPSed (แล้ว) URL ที่เกี่ยวข้องกับโปรโตคอลจะไม่ช่วยในการแก้ปัญหาการรับทรัพย์สินบุคคลที่สามผ่าน HTTP - ไม่มีทาง และต่อไปจะเป็นการดีกว่าถ้าไม่มีโลโก้ SSL สีเขียวสะอาดในหน้า HTTPS ของคุณแทนที่จะให้ HTTP กลับมาอีกครั้งเพียงเพราะบุคคลที่สามยังไม่รองรับ HTTPS

— poige

30

หากคุณใช้ URL ที่ไม่ใช้โปรโตคอลในการโหลดสไตล์ชีท IE 7 และ 8 จะดาวน์โหลดสองครั้ง: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

ดังนั้นนี่คือการหลีกเลี่ยงสำหรับ CSS ถ้าคุณชอบประสิทธิภาพที่ดี

— ทิมพิธีการ
แหล่งที่มา

5

จริง แต่สิ่งนี้กลายเป็นเหตุผลน้อยลงที่จะหลีกเลี่ยงการใช้ URL แบบ schemeless เนื่องจากส่วนแบ่งการตลาดของ IE 7 และ 8 ลดลง

— Simon Lieschke

15

ใช่การอ้างอิงเส้นทางเครือข่ายได้ระบุไว้แล้วในRFC 1808และควรทำงานกับเบราว์เซอร์ทั้งหมด

— ต้นกระเจี๊ยบ
แหล่งที่มา

11

ขอแนะนำและใช้งานในโค้ดแผ่น HTML5: html5boilerplate.com

— Felipe Lima

1

เล็กน้อยใช่คุณไม่ตอบว่าใช่ "มีคำเตือนอื่น ๆ อีกหรือไม่?" ? ;)

— Caspar Kleijne

2

@ คาสปาร์ Kleijne: ฉันอธิบายใช่กับส่วนที่เหลือของประโยค

— Gumbo

1

แคสเปอร์กัมโบได้ตอบคำถามทั้งสองที่ถามว่า: "นี่เป็นเบราว์เซอร์ที่เข้ากันได้อย่างสมบูรณ์หรือไม่? ใช่คือคำตอบของคำถามแรก

— Darren Griffith

4

นี่เป็นเบราว์เซอร์ที่เข้ากันได้อย่างสมบูรณ์หรือไม่? มีข้อแม้อื่น ๆ อีกไหม?

เพียงแค่โยนสิ่งนี้ไปผสมถ้าคุณกำลังพัฒนาบนเซิร์ฟเวอร์ภายในเครื่องมันอาจไม่ทำงาน คุณต้องระบุรูปแบบมิฉะนั้นเบราว์เซอร์อาจถือว่านั่นsrc="//cdn.example.com/js_file.js"คือsrc="file://cdn.example.com/js_file.js"ซึ่งจะแตกเนื่องจากคุณไม่ได้โฮสต์ทรัพยากรนี้ในเครื่อง

Microsoft Internet Explorer ดูเหมือนจะมีความละเอียดอ่อนโดยเฉพาะอย่างยิ่งดูคำถามนี้: ไม่สามารถโหลด jQuery ใน Internet Explorer บน localhost (WAMP)

คุณอาจพยายามหาวิธีแก้ปัญหาที่ใช้ได้กับทุกสภาพแวดล้อมของคุณด้วยจำนวนการแก้ไขที่น้อยที่สุด

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

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

ฉันโพสต์คำตอบนี้ที่นี่เช่นกัน

UPDATE: HTML5Boilerplateตอนนี้ใช้<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">หลังจากที่ตัดสินใจโปรโตคอล URL สัมพัทธ์การเลิกดูที่นี่

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

1

ฉันไม่ได้มีปัญหาเหล่านี้เมื่อใช้: //domain.com - แต่คุณต้องเพิ่มโคลอนในตอนต้น Yoast เขียนบทความได้ดีในช่วงนี้ แต่มันหายไปในกองโพสต์บล็อกของเขา

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

ลงคะแนนเพื่อไม่ระบุตำแหน่งเพิ่มเติม: มีประโยชน์ ทุกครั้งที่ฉันออกจาก ":" ลิงค์ยากไร้

— ปล้น

0

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

Content-Security-Policy: upgrade-insecure-requests;

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

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