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?
Odpowiedzi:
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.
źródło
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:
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:
Opisywany identyfikator URI jest względnym identyfikatorem URI bez schematu.
źródło
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).źródło
script src="//..."
nie działał! Otwierałem plik HTML lokalnie!Wiele osób nazywa to relatywnym adresem URL protokołu.
Powoduje to podwójne pobranie plików CSS w IE 7 i 8 .
źródło
Tutaj powielam odpowiedź w Ukrytych funkcjach HTML :
źródło
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
źródło
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"
tosrc="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:
AKTUALIZACJA: HTML5Boilerplate używa teraz
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
po podjęciu decyzji o wycofaniu względnych adresów URL protokołu, patrz [tutaj] [3].źródło
Zgodnie z odniesieniem gnuda, RFC 3986 sekcja 5.2 mówi:
Tak
//
jest poprawne :-)źródło
Tak, jest to udokumentowane w RFC 3986 , sekcja 5.2:
(edycja: Ups, moje odniesienie do RFC było nieaktualne).
źródło
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:
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.
źródło
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:
Żądanie 404:
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.
źródło
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ż:
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ń :
3.2 Kolejne linki
3.3 Przykłady
https
4. Proces opracowywania
Na przykład próbuję użyć czystej konsoli .
KiraCleanConsole__cdn_links_demo.html
:Link
//cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js
jest prawidłowy, ale pojawia się błąd.Zwróć uwagę
file://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js
i 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:
Developing process
pozycji, możesz ustawić przepływ pracy programistycznej.Third-party tools
elemencie możesz wnieść narzędzia.Ale nie potrzebujesz tych dodatkowych problemów. Przeczytaj informacje według linków w
Anti-pattern
elemencie: Adresy URL zależne od protokołu są nieaktualne.źródło
Wzór, który widzę na html5 -ilerplate jest:
To działa płynnie na różnych systemów, takich jak
http
,https
,file
.źródło
https://
do wszystkiegohttps://
wszędzie polega na tym, że musisz ciągle sprawdzać wszystkie linki zewnętrzne, aby zobaczyć, czy faktycznie je obsługują, i zmienić je na,http://
jeśli nie działają (w przeciwnym razie nie będą działać). Może to być kłopotliwe w przypadku dużej liczby linków.https://
powinien (lub może) zostać użyty we wszystkich linkach, co jest nieprawidłowe.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.
źródło