Czy warto zamienić http: // na // w <script src = „http: //…”>?

Mam następujący element:

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

W takim przypadku witryna to HTTPS, ale może to być również HTTP. (Plik JS znajduje się w innej domenie.) Zastanawiam się, czy dla wygody można wykonać następujące czynności:

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

Zastanawiam się, czy usunięcie http:lub jest poprawne https:?

Wydaje się, że działa wszędzie, gdzie testowałem, ale czy są jakieś przypadki, w których nie działa?

Względny adres URL bez schematu (http: lub https :) jest prawidłowy, zgodnie z RFC 3986: „Identyfikator URI: jednolita składnia”, sekcja 4.2 . Jeśli klient dusi się na nim, jest to wina klienta, ponieważ nie przestrzega składni URI określonej w RFC.

Twój przykład jest prawidłowy i powinien działać. Użyłem tej metody względnego adresu URL na stronach o dużym natężeniu ruchu i nie otrzymałem żadnych skarg. Testujemy również nasze witryny w Firefox, Safari, IE6, IE7 i Opera. Wszystkie te przeglądarki rozumieją ten format adresu URL.

Gwarantujemy, że będzie działać w dowolnej głównej przeglądarce (nie biorę pod uwagę przeglądarek z mniejszym niż 0,05% udziałem w rynku). Do licha, działa w przeglądarce Internet Explorer 3.0.

RFC 3986 definiuje identyfikator URI składający się z następujących części:

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

Podczas definiowania względnych identyfikatorów URI ( sekcja 5.2 ) można pominąć dowolną z tych sekcji, zawsze zaczynając od lewej. W pseudokodzie wygląda to tak:

 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;

Opisywany identyfikator URI jest względnym identyfikatorem URI bez schematu.

czy są jakieś przypadki, w których to nie działa?

Jeśli strona nadrzędna została załadowana file://, to prawdopodobnie nie działa (spróbuje uzyskać file://cdn.example.com/js_file.js, co oczywiście możesz również podać lokalnie).

Wiele osób nazywa to relatywnym adresem URL protokołu.

Powoduje to podwójne pobranie plików CSS w IE 7 i 8 .

Tutaj powielam odpowiedź w Ukrytych funkcjach HTML :

Korzystanie z bezwzględnej ścieżki niezależnej od protokołu:

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

Jeśli przeglądarka przegląda stronę w SSL za pośrednictwem HTTPS, zażąda tego zasobu za pomocą protokołu https, w przeciwnym razie zażąda tego za pomocą HTTP.

Zapobiega to okropnemu komunikatowi o błędzie „Ta strona zawiera zarówno elementy zabezpieczone, jak i niezabezpieczone” w IE, utrzymując wszystkie żądania zasobów w tym samym protokole.

Ostrzeżenie: W przypadku użycia w <link>lub w imporcie arkusza stylów IE7 i IE8 dwukrotnie pobierają plik . Wszystkie pozostałe zastosowania są jednak w porządku.

Całkowicie uzasadnione jest pominięcie protokołu. Specyfikacja adresu URL jest od lat bardzo jasna i jeszcze nie znalazłem przeglądarki, która tego nie rozumie. Nie wiem, dlaczego ta technika nie jest lepiej znana; to idealne rozwiązanie drażliwego problemu przekraczania granic HTTP / HTTPS. Więcej tutaj: Przejścia Http-https i względne adresy URL

czy są jakieś przypadki, w których to nie działa?

Wystarczy wrzucić to do miksu, jeśli tworzysz na lokalnym serwerze, może nie działać. Musisz podać schemat, w przeciwnym razie przeglądarka może zakładać, że src="//cdn.example.com/js_file.js"to src="file://cdn.example.com/js_file.js", co złamie ponieważ nie jesteś gospodarzem tego zasobu lokalnie.

Microsoft Internet Explorer wydaje się być szczególnie wrażliwy na to, zobacz to pytanie: Nie można załadować jQuery w Internet Explorerze na localhost (WAMP)

Prawdopodobnie zawsze starałbyś się znaleźć rozwiązanie, które działa we wszystkich twoich środowiskach przy minimalnej ilości potrzebnych modyfikacji.

Rozwiązaniem używanym przez HTML5Boilerplate jest wycofanie się, gdy zasób nie zostanie poprawnie załadowany, ale działa to tylko wtedy, gdy uwzględnisz czek:

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

AKTUALIZACJA: HTML5Boilerplate używa teraz <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jspo podjęciu decyzji o wycofaniu względnych adresów URL protokołu, patrz [tutaj] [3].

Zgodnie z odniesieniem gnuda, RFC 3986 sekcja 5.2 mówi:

Jeśli komponent schematu jest zdefiniowany, co wskazuje, że odwołanie zaczyna się od nazwy schematu, wówczas odwołanie jest interpretowane jako bezwzględny identyfikator URI i gotowe. W przeciwnym razie schemat referencyjnego identyfikatora URI jest dziedziczony z podstawowego komponentu schematu URI .

Tak //jest poprawne :-)

Tak, jest to udokumentowane w RFC 3986 , sekcja 5.2:

(edycja: Ups, moje odniesienie do RFC było nieaktualne).

Jest to rzeczywiście poprawne, jak stwierdzono w innych odpowiedziach. Należy jednak pamiętać, że niektóre roboty indeksujące uruchomią dla nich 404, żądając ich na serwerze, jakby to był lokalny adres URL. (Ignorują podwójny ukośnik i traktują go jako pojedynczy ukośnik).

Możesz ustawić regułę na swoim serwerze internetowym, aby złapać je i przekierować.

Na przykład w Nginx można dodać coś takiego:

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

Pamiętaj jednak, że jeśli używasz kropek w swoich identyfikatorach URI, musisz zwiększyć specyficzność, w przeciwnym razie spowoduje to przekierowanie tych stron do nieistniejących domen.

Ponadto jest to dość masywne wyrażenie regularne, które należy uruchamiać dla każdego zapytania - moim zdaniem warto ukarać przeglądarki niezgodne 404s za (niewielki) spadek wydajności w większości zgodnych przeglądarek.

Podczas używania //somedomain.com jako odniesień do plików JS widzimy błędy 404 w naszych logach.

Referencje, które powodują 404, wyglądają tak: ref:

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

Żądanie 404:

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

Ponieważ są one regularnie wyświetlane w dziennikach naszego serwera WWW, można śmiało powiedzieć, że: Wszystkie przeglądarki i boty NIE honorują RFC 3986 sekcja 4.2. Najbezpieczniejszym zakładem jest dołączenie protokołu w miarę możliwości.

1. Podsumowanie

Odpowiedź na rok 2019: nadal możesz używać adresów URL zależnych od protokołu, ale ta technika jest anty-wzorcem .

Również:

1. Możesz mieć problemy z rozwojem.
2. Niektóre narzędzia innych firm mogą ich nie obsługiwać.

Migracja z adresów URL zależnych od protokołu https://byłaby miła.

2. Trafność

Ta odpowiedź dotyczy stycznia 2019 r. W przyszłości dane tej odpowiedzi mogą być nieaktualne.

3. Anty-wzór

3.1 Argumentacja

Paul Irish - inżynier i rzecznik programistów Google Chrome - napisz w 2014 r., Grudzień :

Teraz, gdy protokół SSL jest wspierany przez wszystkich i nie ma problemów z wydajnością , ta technika jest teraz anty-wzorcem . Jeśli potrzebny zasób jest dostępny w protokole SSL, zawsze używaj go https://.

Zezwolenie fragmentowi na żądanie przez HTTP otwiera drzwi do ataków, takich jak niedawny atak GitHub Man-on-the-side . Żądanie zasobów HTTPS jest zawsze bezpieczne, nawet jeśli witryna korzysta z HTTP, jednak odwrotna sytuacja nie jest prawdą .

3.2 Kolejne linki

• Ładuje zasoby strony przy użyciu względnych protokołów URI
• Przestań używać adresów URL zależnych od protokołu

3.3 Przykłady

• W 2017 r. Przepełnienie stosu zostało zmienione z adresów URL zależnych od protokołu na https
• W 2018 r. Chrome oznaczy wszystkie niezaszyfrowane witryny jako „niezabezpieczone”

4. Proces opracowywania

Na przykład próbuję użyć czystej konsoli .

• Przykładowy plik 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>

• wynik:

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

Link //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsjest prawidłowy, ale pojawia się błąd.

Zwróć uwagę file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsi przeczytaj Thilo i bg17aw odpowiedzi na tematfile://.

Nie wiedziałem o tym zachowaniu i nie mogłem zrozumieć, dlaczego mam takie problemy z pageres .

5. Narzędzia innych firm

Używam klikalnego pakietu URL Sublime Text. Użyj go, mogę po prostu otworzyć linki z mojego edytora tekstu w przeglądarce.

Oba linki w przykładzie są prawidłowe. Ale pierwszy link, który mogę z powodzeniem otworzyć w przeglądarce, wykorzystuje klikalne adresy URL, drugi link - nie. To może nie być zbyt wygodne.

6. Wniosek

Tak:

1. Jeśli masz problemy jak w Developing process pozycji, możesz ustawić przepływ pracy programistycznej.
2. W przeciwnym razie masz problemy, ponieważ w Third-party toolselemencie możesz wnieść narzędzia.

Ale nie potrzebujesz tych dodatkowych problemów. Przeczytaj informacje według linków w Anti-patternelemencie: Adresy URL zależne od protokołu są nieaktualne.

Wzór, który widzę na html5 -ilerplate jest:

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

To działa płynnie na różnych systemów, takich jak http, https, file.

Ponieważ Twoim przykładem jest linkowanie do domeny zewnętrznej, jeśli używasz HTTPS, powinieneś sprawdzić, czy domena zewnętrzna jest skonfigurowana również dla SSL. W przeciwnym razie użytkownicy mogą zobaczyć błędy SSL i / lub błędy 404 (np. Starsze wersje Plesk przechowują HTTP i HTTPS w osobnych folderach). W przypadku CDN nie powinno to stanowić problemu, ale w przypadku każdej innej witryny może być.

Na marginesie, przetestowany podczas aktualizacji starej strony, a także działa w url = część META REFRESH.