มันถูกต้องหรือไม่ที่จะแทนที่ http: // ด้วย // ใน <script src =“ http: // …”>?

ฉันมีองค์ประกอบดังต่อไปนี้:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

ในกรณีนี้ไซต์คือ HTTPS แต่ไซต์นั้นอาจเป็นเพียง HTTP (ไฟล์ JS อยู่ในโดเมนอื่น) ฉันสงสัยว่ามันถูกต้องหรือไม่ที่จะทำสิ่งต่อไปนี้เพื่อความสะดวก:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

ฉันสงสัยว่าการลบhttp:หรือhttps:?

ดูเหมือนว่าจะทำงานได้ทุกที่ที่ฉันทดสอบ แต่มีบางกรณีที่มันไม่ทำงานหรือไม่

URL ที่ญาติโดยไม่ต้องโครงการ (http: หรือ https :) ถูกต้องต่อRFC 3986: "Uniform Resource Identifier (URI): ทั่วไปไวยากรณ์" มาตรา 4.2 หากไคลเอนต์ทำการติดตั้งแสดงว่าเป็นความผิดพลาดของไคลเอ็นต์เนื่องจากไม่ปฏิบัติตามไวยากรณ์ URI ที่ระบุใน RFC

ตัวอย่างของคุณถูกต้องและควรใช้งานได้ ฉันใช้วิธี URL แบบสัมพัทธ์กับตัวเองในเว็บไซต์ที่มีการค้ามนุษย์จำนวนมากและไม่มีข้อร้องเรียน นอกจากนี้เราทดสอบเว็บไซต์ของเราใน Firefox, Safari, IE6, IE7 และ Opera เบราว์เซอร์เหล่านี้ทุกคนเข้าใจรูปแบบ URL นั้น

มันรับประกันว่าจะทำงานในเบราว์เซอร์หลักใด ๆ (ฉันไม่ได้พิจารณาเบราว์เซอร์ที่มีส่วนแบ่งการตลาดน้อยกว่า 0.05%) Heck ใช้งานได้ใน Internet Explorer 3.0

RFC 3986กำหนด URI ซึ่งประกอบด้วยชิ้นส่วนต่อไปนี้:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

เมื่อกำหนด URIs ที่เกี่ยวข้อง ( ส่วน 5.2 ) คุณสามารถละเว้นส่วนใด ๆ เหล่านั้นโดยเริ่มต้นจากด้านซ้าย ในโค้ดหลอกดูเหมือนว่า:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

URI ที่คุณกำลังอธิบายเป็น URI ที่สัมพันธ์กับแบบแผนน้อยกว่า

มีกรณีใดบ้างที่ใช้ไม่ได้

หากเพจระดับบนถูกโหลดมาแสดงfile://ว่าอาจไม่ทำงาน (จะพยายามรับfile://cdn.example.com/js_file.jsซึ่งแน่นอนว่าคุณสามารถให้บริการแบบในเครื่องด้วย)

หลายคนเรียกสิ่งนี้ว่า URL ที่สัมพันธ์กับโปรโตคอล

มันทำให้เกิดสองครั้งดาวน์โหลดไฟล์ CSS ใน IE 7 และ 8

ที่นี่ฉันซ้ำคำตอบในคุณสมบัติที่ซ่อนของ HTML :

การใช้พา ธ สัมบูรณ์ที่ไม่ขึ้นอยู่กับโปรโตคอล:

<img src="//domain.com/img/logo.png"/>

หากเบราว์เซอร์กำลังดูหน้าใน SSL ผ่าน HTTPS ก็จะขอเนื้อหานั้นด้วยโปรโตคอล https มิฉะนั้นจะขอด้วย HTTP

สิ่งนี้ป้องกันไม่ให้ข้อความแสดงข้อผิดพลาด "หน้านี้มีทั้งรายการที่ปลอดภัยและไม่ปลอดภัย" ใน IE ทำให้คำขอสินทรัพย์ของคุณทั้งหมดอยู่ในโปรโตคอลเดียวกัน

ข้อแม้: เมื่อใช้เป็น<link>หรือ @import สำหรับสไตล์ชีต, IE7 และ IE8 ดาวน์โหลดไฟล์สองครั้ง อย่างไรก็ตามการใช้งานอื่นทั้งหมดนั้นใช้ได้

มันสมบูรณ์แบบที่จะออกจากโปรโตคอล ข้อมูลจำเพาะของ URL ชัดเจนเกี่ยวกับเรื่องนี้มานานหลายปีแล้วและฉันยังไม่พบเบราว์เซอร์ที่ไม่เข้าใจ ฉันไม่รู้ว่าทำไมเทคนิคนี้จึงไม่ค่อยเป็นที่รู้จัก มันเป็นโซลูชั่นที่สมบูรณ์แบบสำหรับปัญหาที่ยุ่งยากของการข้ามขอบเขต HTTP / HTTPS เพิ่มเติมได้ที่นี่: การเปลี่ยน Http-https และ URL สัมพัทธ์

มีกรณีใดบ้างที่ใช้ไม่ได้

เพียงแค่โยนสิ่งนี้ไปผสมถ้าคุณกำลังพัฒนาบนเซิร์ฟเวอร์ภายในเครื่องมันอาจไม่ทำงาน คุณต้องระบุรูปแบบมิฉะนั้นเบราว์เซอร์อาจถือว่านั่น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>

อัปเดต: ตอนนี้HTML5Boilerplateใช้<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jsหลังจากตัดสินใจเลิกใช้ URL ที่เกี่ยวข้องกับโปรโตคอลโปรดดู [ที่นี่] [3]

ตามการอ้างอิงของ gnud RFC 3986 ส่วน 5.2กล่าวว่า:

หากมีการกำหนดองค์ประกอบของโครงการแสดงว่าการอ้างอิงเริ่มต้นด้วยชื่อของโครงการดังนั้นการอ้างอิงจะถูกตีความว่าเป็น URI แบบสัมบูรณ์และเราเสร็จแล้ว มิฉะนั้นโครงการอ้างอิง URI ที่จะรับมาจากองค์ประกอบโครงการฐาน

ดังนั้น//ถูกต้อง :-)

ใช่มีการบันทึกไว้ในRFC 3986ส่วนที่ 5.2:

(แก้ไข: โอ๊ะการอ้างอิง RFC ของฉันล้าสมัยแล้ว)

มันถูกต้องแน่นอนตามคำตอบอื่น ๆ ที่ระบุไว้ คุณควรทราบว่าตัวรวบรวมข้อมูลเว็บบางตัวจะปิด 404s สำหรับสิ่งเหล่านี้โดยขอให้พวกเขาบนเซิร์ฟเวอร์ของคุณราวกับว่าเป็น URL ท้องถิ่น (พวกเขาไม่สนใจเครื่องหมายทับสองครั้งและถือว่าเป็นเครื่องหมายทับเดียว)

คุณอาจต้องการตั้งค่ากฎบนเว็บเซิร์ฟเวอร์ของคุณเพื่อจับสิ่งเหล่านี้และเปลี่ยนเส้นทาง

ตัวอย่างเช่นด้วย Nginx คุณจะต้องเพิ่มสิ่งต่อไปนี้:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

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

นอกจากนี้นี่เป็น regex ที่ค่อนข้างใหญ่ที่จะเรียกใช้สำหรับการค้นหาแต่ละครั้ง - ในความคิดของฉันมันคุ้มค่าที่จะลงโทษเบราว์เซอร์ที่ไม่เป็นไปตามมาตรฐานที่มี 404s มากกว่า (เล็กน้อย) ประสิทธิภาพการทำงาน

เราพบข้อผิดพลาด 404 ข้อในบันทึกของเราเมื่อใช้ //somedomain.com เป็นการอ้างอิงถึงไฟล์ JS

การอ้างอิงที่ทำให้ยุค 404 ออกมาเป็นแบบนี้: ref:

<script src="//somedomain.com/somescript.js" />

คำขอ 404:

http://mydomain.com//somedomain.com/somescript.js

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

1. สรุป

คำตอบสำหรับปี 2019: คุณยังสามารถใช้ URL ที่สัมพันธ์กับโปรโตคอลได้ แต่เทคนิคนี้ เป็นรูปแบบการต่อต้านต่อต้านรูปแบบ

นอกจากนี้:

1. คุณอาจมีปัญหาในการพัฒนา
2. เครื่องมือของบุคคลที่สามบางตัวอาจไม่รองรับ

การโอนย้ายจาก URL ที่สัมพันธ์กับโปรโตคอลhttps://จะเป็นการดี

2. ความเกี่ยวข้อง

คำตอบนี้มีความเกี่ยวข้องสำหรับมกราคม 2019 ในอนาคตข้อมูลของคำตอบนี้อาจล้าสมัย

3. ต่อต้าน - รูปแบบ

3.1 การโต้แย้ง

Paul Irish - วิศวกรหน้าและผู้ให้การสนับสนุนผู้พัฒนา Google Chrome - เขียนในปี 2014 ธันวาคม :

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

การอนุญาตให้สนิปเพตร้องขอ HTTP จะเปิดประตูสำหรับการโจมตีเช่นการโจมตีแบบGitHub แบบ Man-on-the-sideล่าสุด มันเสมอปลอดภัยในการขอ HTTPS สินทรัพย์แม้ว่าเว็บไซต์ของคุณอยู่ใน HTTP แต่กลับไม่เป็นความจริง

3.2 ลิงค์อื่น

• โหลดทรัพยากรหน้าเว็บโดยใช้ URI ที่สัมพันธ์กับโปรโตคอล
• หยุดใช้ URL ที่สัมพันธ์กับโปรโตคอล

3.3 ตัวอย่าง

• ในปี 2560 สแต็คโอเวอร์โฟลว์เปลี่ยนจาก URL ที่สัมพันธ์กับโปรโตคอลเป็น https
• ในปี 2018 Chrome จะติดธงทำเครื่องหมายเว็บไซต์ที่ไม่ได้เข้ารหัสทั้งหมดว่า“ ไม่ปลอดภัย”

4. การพัฒนากระบวนการ

ตัวอย่างเช่นผมพยายามที่จะใช้ทำความสะอาดคอนโซล

• ไฟล์ตัวอย่างKiraCleanConsole__cdn_links_demo.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• เอาท์พุท:

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

ลิงก์//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsใช้ได้ แต่ฉันพบข้อผิดพลาด

เอาใจใส่file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsและอ่านThiloและbg17awfile://คำตอบเกี่ยวกับ

ผมไม่ทราบว่าเกี่ยวกับพฤติกรรมนี้และไม่เข้าใจว่าทำไมผมมีปัญหาเช่นนี้ pageres

5. เครื่องมือของบุคคลที่สาม

ฉันใช้แพ็คเกจข้อความ Sublime URL ที่สามารถคลิกได้ ใช้มันฉันสามารถเปิดลิงก์จากโปรแกรมแก้ไขข้อความในเบราว์เซอร์

ลิงก์ทั้งสองตัวอย่างนั้นถูกต้อง แต่ลิงค์แรกที่ฉันสามารถเปิดได้ในเบราว์เซอร์ใช้ URL ที่สามารถคลิกได้ลิงก์ที่สอง - ไม่ใช่ สิ่งนี้อาจไม่สะดวกนัก

6. สรุป

ใช่:

1. หากคุณมีปัญหาตามมา Developing processรายการคุณสามารถตั้งค่าเวิร์กโฟลว์การพัฒนาของคุณ
2. หากคุณมีปัญหาตามที่ระบุไว้ในThird-party toolsรายการคุณสามารถมีส่วนร่วมในเครื่องมือต่างๆ

แต่คุณไม่ต้องการปัญหาเพิ่มเติมนี้ อ่านข้อมูลตามลิงค์ในAnti-patternรายการ: URL ที่สัมพันธ์กับโปรโตคอลล้าสมัย

รูปแบบที่ฉันเห็นในhtml5-boilerplateคือ:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

มันทำงานได้อย่างราบรื่นในรูปแบบที่แตกต่างกันเช่นhttp, ,httpsfile

เนื่องจากตัวอย่างของคุณเชื่อมโยงไปยังโดเมนภายนอกหากคุณใช้ HTTPS คุณควรตรวจสอบว่าโดเมนภายนอกนั้นได้รับการตั้งค่าสำหรับ SSL เช่นกัน มิฉะนั้นผู้ใช้ของคุณอาจเห็นข้อผิดพลาด SSL และ / หรือข้อผิดพลาด 404 (เช่นเวอร์ชันเก่าของ Plesk เก็บ HTTP และ HTTPS ในโฟลเดอร์แยกต่างหาก) สำหรับ CDN นั้นไม่น่าจะมีปัญหา แต่สำหรับเว็บไซต์อื่น ๆ

ในหมายเหตุด้านทดสอบในขณะที่ปรับปรุงเว็บไซต์เก่าและยังทำงานใน url = ส่วนหนึ่งของการอ้างอิงของ META