<Script src = “http: //…”> içinde http: // yerine // koymak geçerli mi?

Aşağıdaki öğeye sahibim:

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

Bu durumda site HTTPS'dir, ancak site yalnızca HTTP de olabilir. (JS dosyası başka bir etki alanında.) Kolaylık uğruna aşağıdakileri yapmak için geçerli olup olmadığını merak ediyorum:

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

Ben kaldırmak için geçerli olmadığını merak ediyorum http:ya https:?

Test ettiğim her yerde çalışıyor gibi görünüyor, ancak çalışmadığı durumlar var mı?

Şema içermeyen göreceli bir URL (http: veya https :) RFC 3986 için geçerlidir : "Tekdüzen Kaynak Tanımlayıcısı (URI): Genel Sözdizimi", Bölüm 4.2 . Bir istemci bunu boğarsa, RFC'de belirtilen URI sözdizimine uymadıkları için istemcinin hatasıdır.

Örneğiniz geçerlidir ve çalışmalıdır. Bu göreli URL yöntemini yoğun şekilde trafik işlemleri yapılan sitelerde kullandım ve sıfır şikayetim oldu. Ayrıca, sitelerimizi Firefox, Safari, IE6, IE7 ve Opera'da test ediyoruz. Bu tarayıcıların tümü bu URL biçimini anlar.

Herhangi bir genel tarayıcıda çalışacağı garanti edilir (% 0.05'ten daha az pazar payına sahip tarayıcıları dikkate almıyorum). Heck, Internet Explorer 3.0'da çalışır.

RFC 3986 , bir URI'yi aşağıdaki bölümlerden oluşan şekilde tanımlar:

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

Göreli URI'leri tanımlarken ( Bölüm 5.2 ), her zaman soldan başlayarak bu bölümlerden herhangi birini atlayabilirsiniz. Sahte kodda şöyle görünür:

 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;

Tanımladığınız URI, şemasız göreli bir URI'dır.

işe yaramadığı durumlar var mı?

Üst sayfa yüklendiyse file://, muhtemelen işe yaramaz ( file://cdn.example.com/js_file.jselbette yerel olarak da sağlayabileceğinizi almaya çalışacaktır ).

Birçok kişi buna Protokol Göreli URL diyor.

IE 7 ve 8'de CSS dosyalarının çift indirilmesine neden olur .

Burada cevabı HTML'nin Gizli özelliklerinde çoğaltırım :

Protokolden bağımsız bir mutlak yol kullanma:

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

Tarayıcı SSL'de bir sayfayı HTTPS aracılığıyla görüntülüyorsa, o öğeyi https protokolüyle ister, aksi takdirde HTTP ile ister.

Bu, tüm varlık isteklerinizi aynı protokol içinde tutarak IE'deki bu "Güvenli ve Güvenli Olmayan Öğeler İçerir" hata iletisini önler.

Uyarı: Bir <link>stil sayfası için a veya @import'ta kullanıldığında , IE7 ve IE8 dosyayı iki kez indirir . Bununla birlikte, diğer tüm kullanımlar gayet iyi.

Protokolü bırakmak kesinlikle geçerlidir. URL spesifikasyonu bu konuda yıllardır çok açıktı ve henüz anlamayan bir tarayıcı bulamadım. Bu tekniğin neden daha iyi bilinmediğini bilmiyorum; HTTP / HTTPS sınırlarını aşmanın zorlu sorununa mükemmel bir çözümdür. Burada daha fazlası: Http-https geçişleri ve göreli URL'ler

işe yaramadığı durumlar var mı?

Bunu sadece karışıma atmak için, yerel bir sunucu üzerinde geliştiriyorsanız, çalışmayabilir. Aksi tarayıcı farz edebilir, bir plan belirtmek gerekir src="//cdn.example.com/js_file.js"ise src="file://cdn.example.com/js_file.js"yerel olarak bu kaynağı barındıran değiliz çünkü kıracak olan.

Microsoft Internet Explorer buna özellikle duyarlı gibi görünüyor, şu soruya bakın: localhost (WAMP) üzerinde Internet Explorer'da jQuery yüklenemiyor

Muhtemelen her zaman tüm ortamlarınızda en az değişiklik gerektiren bir çözüm bulmaya çalışacaksınız.

HTML5Boilerplate tarafından kullanılan çözüm , kaynak doğru yüklenmediğinde bir geri dönüşe sahip olmaktır , ancak bu yalnızca bir onay eklerseniz çalışır:

<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>

GÜNCELLEME: HTML5Boilerplate artık <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jsprotokole bağlı URL'leri kullanımdan kaldırmaya karar verdikten sonra kullanıyor , bkz. [Burada] [3].

Gnud'un referansını takiben, RFC 3986 bölüm 5.2 :

Şema bileşeni, başvurunun bir şema adıyla başladığını belirten tanımlanırsa, başvuru mutlak bir URI olarak yorumlanır ve işimiz tamamlanır. Aksi takdirde, referans URI'nin şeması temel URI'nin şema bileşeninden devralınır .

Yani //doğrudur :-)

Evet, bu RFC 3986 , bölüm 5.2'de belgelenmiştir :

(değiştir: Hata! RFC referansım eski oldu).

Diğer cevapların belirttiği gibi, bu gerçekten doğrudur. Yine de, bazı web tarayıcılarının bunlar için sunucunuzda yerel bir URL gibi isteyerek 404'ler ayarlayacağını unutmayın. (Çift eğik çizgiyi dikkate almazlar ve tek bir eğik çizgi gibi davranırlar).

Bunları yakalamak ve yönlendirmek için web sunucunuzda bir kural ayarlamak isteyebilirsiniz.

Örneğin, Nginx ile şöyle bir şey eklersiniz:

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

Bununla birlikte, URI'lerinizde nokta kullanırsanız, özgüllüğü artırmanız gerektiğini veya bunun bu sayfaları mevcut olmayan alanlara yönlendireceğini unutmayın.

Ayrıca, bu, her sorgu için çalıştırılması oldukça büyük bir regex - bence, uyumlu tarayıcıların çoğunda (hafif) bir performansta 404'lü uyumlu olmayan tarayıcıları cezalandırmaya değer.

//Somedomain.com'u JS dosyalarına referans olarak kullanırken günlüklerimizde 404 hataları görüyoruz.

404'lere neden olan referanslar şöyle görünür: ref:

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

404 istek:

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

Bu web sunucu günlüklerinde düzenli gösterilmesini ile, söylemek güvenli olduğunu: Tüm tarayıcılar ve Botlar DO DEĞİL namus RFC 3986 bölüm 4.2. En güvenli bahis, mümkün olduğunda protokolü dahil etmektir.

1. Özet

2019 için cevap: yine de protokole bağlı URL'ler kullanabilirsiniz, ancak bu teknik bir anti-desen .

Ayrıca:

1. Geliştirme konusunda sorunlarınız olabilir.
2. Bazı üçüncü taraf araçlar bunları desteklemeyebilir.

Protokole bağlı URL'lerden https://ona geçiş yapmak iyi olurdu.

2. Alaka Düzeyi

Bu cevap Ocak 2019 için geçerlidir. Gelecekte, bu cevabın verileri eski olabilir.

3. Anti-desen

3.1. yargılama

Paul Irish - ön uç mühendis ve Google Chrome için bir geliştirici savunucusu - Aralık 2014'te yaz :

Artık SSL herkes için teşvik edildiğinden ve performans kaygıları olmadığından , bu teknik artık bir anti-kalıptır . İhtiyacınız olan varlık SSL'de varsa, her zaman https://varlığı kullanın .

Snippet'in HTTP üzerinden istekte bulunmasına izin vermek, en son GitHub Man-on-the-side saldırısı gibi saldırıların kapısını açar . Siteniz HTTP'de olsa bile HTTPS öğeleri istemek her zaman güvenlidir, ancak bunun tersi doğru değildir .

3.2. Başka bağlantılar

• Protokole bağlı URI'leri kullanarak sayfa kaynaklarını yükler
• Protokole bağlı URL'leri kullanmayı bırak

3.3. Örnekler

• 2017'de Yığın Taşması, protokole bağlı URL'lerden https
• 2018'de Chrome, şifrelenmemiş tüm web sitelerini "güvenli değil" olarak işaretleyecek

4. Geliştirme süreci

Örneğin, temiz konsol kullanmaya çalışıyorum .

• Örnek dosya 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>

• çıktı:

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

Bağlantı //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsgeçerli, ancak bir hata alıyorum.

Dikkat edin file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsve Thilo ve bg17aw cevaplarını okuyun file://.

Bu davranışı bilmiyordum ve çağrı cihazları için neden böyle problemlerim olduğunu anlayamadım .

5. Üçüncü taraf araçları

Kullandığım tıklanabilir URL'ler Sublime Text paketi. Kullanın, sadece metin düzenleyicimdeki bağlantıları tarayıcıda açabilirim.

Örnekteki her iki bağlantı da geçerlidir. Ancak ilk bağlantıyı tarayıcıda başarıyla açabildiğim Tıklanabilir URL'ler, ikinci bağlantı - hayır. Bu çok uygun olmayabilir.

6. Sonuç

Evet:

1. Öğedeki gibi sorunlarınız varsa Developing process, geliştirme iş akışınızı ayarlayabilirsiniz.
2. Maddede olduğu gibi sorunlarınız Third-party toolsolursa, araçlara katkıda bulunabilirsiniz.

Ancak bu ek sorunlara ihtiyacınız yok. Anti-patternÖğedeki: protokole bağlı URL'lerdeki bağlantılara göre bilgileri okuyun .

Html5-boilerplate üzerinde gördüğüm desen :

<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>

Bu gibi farklı programları üzerine sorunsuz http, https, file.

Örneğiniz harici bir etki alanına bağlandığından, HTTPS kullanıyorsanız harici etki alanının SSL için de ayarlandığını doğrulamanız gerekir. Aksi takdirde, kullanıcılarınız SSL hataları ve / veya 404 hataları görebilir (örn. Plesk'in eski sürümleri HTTP ve HTTPS'yi ayrı klasörlerde depolar). CDN'ler için bu bir sorun olmamalı, ancak başka herhangi bir web sitesi için olabilir.

Bir yan notta, eski bir web sitesini güncellediğinde test edildi ve ayrıca bir META REFRESH'in url = bölümünde çalışıyor.