ทำไมคุณถึงใช้ document.location.protocol แทนที่จะเป็น URL ธรรมดา / นำหน้า

ตัวอย่างเช่น Google Analytics ใช้ document.location.protocol ในสำเร็จรูปเพื่อติดตาม:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

แทน

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = '//www.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

ssl โดเมนย่อยเป็นอาร์กิวเมนต์ปิดเสียงเนื่องจากhttps://www.google-analytics.com/ga.jsทำงานได้ดีอย่างสมบูรณ์

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

แก้ไข:สิ่งนี้ไม่เพียงใช้กับ Google Analytics (ตัวอย่างโดเมนย่อยต่าง ๆ ) สิ่งเดียวกันปรากฏบนหน้าFont Loader API :

wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
    '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';

แน่นอนมันไม่ใช่การกำกับดูแลของทีม GA!
ตัวโหลด GA โหลดสคริปต์ดังนั้นจึงไม่ได้รับผลกระทบจากข้อผิดพลาดในการดาวน์โหลดสองครั้งบน<link>หรือ@importสำหรับสไตล์ชีตใน IE7 / IE8

พวกเขาใช้เงื่อนไข (ternary) ผู้ประกอบการในdocument.location.protocol เนื่องจากมีข้อผิดพลาดขอบในกรณี IE6 ที่เป็นสาเหตุของการรักษาความปลอดภัยโต้ตอบจะปรากฏขึ้นภายใต้การตั้งค่าความปลอดภัยบางอย่างเมื่อร้องขอจากไม่ใช่'ssl' โดเมนย่อย , ตามที่อธิบายไว้โดยพอลไอริช (ที่ทำงาน ร่วมกับนักพัฒนาซอฟต์แวร์จาวาสคริปต์ของ Google Analytics เกี่ยวกับเรื่องนี้) ในบล็อกของเขา: https://www.paulirish.com/2010/the-protocol-relative-url/ซึ่งฉันอ้างถึงด้านล่าง:

2011.01.23: แต่ ... สิ่งที่เกี่ยวกับการใช้สิ่งนี้ในตัวอย่างของ Google Analytics ?

ใช่แน่นอนว่ามันจะไม่ดี ... ดังนั้นฉันจึงทำงานร่วมกับนักพัฒนานำจาวาสคริปต์ของ Google Analytics (พระเจ้าฉันรักที่ทำงานที่ google) เพื่อดูว่าเราสามารถทำสิ่งนี้ได้หรือไม่ ... กลายเป็นว่าเราทำไม่ได้ มีบั๊ก edgecase ใน IE6 ที่ทำให้กล่องโต้ตอบระเบิด ... ภายใต้การตั้งค่าความปลอดภัยบางอย่าง (ไม่แน่ใจว่าเป็นค่าเริ่มต้น) เมื่อร้องขอจากโดเมนย่อยที่ไม่ใช่ slsl ภาพหน้าจอที่นี่ ดังนั้นคุณสามารถถอดข้อมูลโค้ด GA ของคุณได้ 40 ไบต์หากคุณไม่สนใจ IE6 .. มิฉะนั้นคุณจะต้องใช้ตัวดำเนินการที่สาม `:)`

2011/12/24 Eric Law (จากทีม IE) เลือกว่าทำไม IE6 เล่นได้ไม่ดี GA ...

สาเหตุที่ไม่สามารถใช้งานได้ใน IE6 คือเซิร์ฟเวอร์กำลังใช้ SNI เพื่ออนุมานว่าใบรับรองใดที่จะส่งคืน XP (และทำให้ IE6) ไม่สนับสนุน SNI ใน HTTPS สแต็ค ดูรายละเอียด

อย่างน้อยมีหนึ่งปัญหาใน IE เพราะทำให้เกิดการดาวน์โหลดซ้ำ: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

คุณชี้แล้วออกมาแตกต่างกันในกรณีของ Google Analytics คือว่ารุ่นที่เชื่อถือได้อยู่บนแทนhttps://ssl. http://www.แม้ว่ารุ่นที่ปลอดภัยของ www อาจใช้งานได้ แต่อาจแตกต่างจากรุ่น ssl:

• ใบรับรองที่แตกต่างกันสำหรับเวอร์ชัน ssl และ www
• รหัสที่แตกต่างกันในแต่ละรุ่น
• ชุดคุกกี้ที่แตกต่างกันโดยเฉพาะสำหรับโดเมน SSL

ฉันไม่รู้ว่าสิ่งเหล่านี้เกี่ยวข้องกับ Google หรือไม่ จากรหัสมองไปที่เดียวกัน

คำตอบของ Stack Overflow ทำให้ได้คะแนนที่ดี

มันเป็นสิ่งสำคัญที่จะต้องระบุโปรโตคอลอย่างชัดเจนเพื่อให้สินทรัพย์เป้าหมายถูกโหลดอย่างถูกต้องภายในเอกสารที่เปิดจากไดรฟ์ในเครื่อง ( file:) หรือเมื่อใช้ "iframe magic" ( about:)

//www.google-analytics.com/ga.jsไม่ใช่ URL ตามมาตรฐานเนื่องจากไม่มีรูปแบบซึ่งจำเป็นต้องมี ใช้งานได้และใช้งานแล้ว แต่ก็ยังไม่สอดคล้องกับมาตรฐาน URL

ดู RFC3986 §3:

ต้องมีส่วนประกอบของ schema และเส้นทางแม้ว่าเส้นทางอาจว่างเปล่า (ไม่มีอักขระ) เมื่อมีสิทธิใช้งานพา ธ ต้องว่างเปล่าหรือขึ้นต้นด้วยอักขระสแลช ("/") เมื่อไม่มีการให้สิทธิ์เส้นทางจะไม่สามารถเริ่มต้นด้วยอักขระทับสองตัว ("//")