Czy jest jakaś wada używania wiodącego podwójnego ukośnika do dziedziczenia protokołu w adresie URL? tj. src = „// domena.com”

Mam arkusz stylów, który ładuje obrazy z domeny zewnętrznej i potrzebuję go do załadowania z https: // ze stron bezpiecznego zamówienia i http: // z innych stron, na podstawie bieżącego adresu URL. Okazało się, że rozpoczęcie adresu URL podwójnym ukośnikiem dziedziczy obecny protokół. Czy wszystkie przeglądarki obsługują tę technikę?

html ex:

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

css ex:

.class { background: url(//cdn.domain.com/logo.png); }

Jeśli przeglądarka obsługuje RFC 1808 sekcja 4 , RFC 2396 sekcja 5.2 lub RFC 3986 sekcja 5.2 , to rzeczywiście będzie używać schematu adresu URL strony dla odniesień zaczynających się od „//”.

W przypadku korzystania z linklub @import, IE7 / IE8 pobierze plik dwukrotnie na http://paulirish.com/2010/the-protocol-relative-url/

Aktualizacja z 2014 roku:

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

Jeden minus występuje, jeśli Twoje adresy URL są przeglądane poza kontekstem strony internetowej. Na przykład wiadomość e-mail znajdująca się w kliencie poczty e-mail (powiedzmy Outlook) faktycznie nie ma adresu URL, a kiedy przeglądasz wiadomość zawierającą adres URL zależny od protokołu, nie ma w ogóle oczywistego kontekstu protokołu (sama wiadomość jest niezależna protokołu używanego do pobrania, czy to POP3, IMAP, Exchange, uucp czy cokolwiek innego), więc adres URL nie ma protokołu, do którego mógłby być względny. Nie badałem zgodności z klientami poczty e-mail, aby zobaczyć, co robią, gdy pojawia się brakujący moduł obsługi protokołu - domyślam się, że większość zgadnie z http. Apple Mail odmawia wprowadzenia adresu URL bez protokołu. Jest to analogiczne do sposobu, w jaki względne adresy URL nie działają w wiadomościach e-mail z powodu podobnie brakującego kontekstu.

Podobne problemy mogą wystąpić w innych kontekstach innych niż HTTP, takich jak tweety, wiadomości SMS, dokumenty Word itp.

Bardziej ogólnym wyjaśnieniem jest to, że anonimowe adresy URL protokołów nie mogą działać w izolacji; tam musi być istotnym kontekstem. W przypadku typowej strony internetowej można więc w ten sposób pobrać bibliotekę skryptów, ale wszelkie linki zewnętrzne powinny zawsze określać protokół. Wypróbowałem jeden prosty test: //stackoverflow.commapy file:///stackoverflow.comwe wszystkich przeglądarkach, w których go wypróbowałem, więc naprawdę nie działają same.

Powodem może być zapewnienie przenośnych stron internetowych. Jeśli strona zewnętrzna nie jest przesyłana w postaci zaszyfrowanej (http), dlaczego połączone skrypty mają być szyfrowane? Wydaje się, że jest to niepotrzebna utrata wydajności. W przypadku, gdy zewnętrzna strona jest bezpiecznie przesyłana w postaci zaszyfrowanej (https), zawartość, do której prowadzi łącze, również powinna być zaszyfrowana. Jeśli strona jest zaszyfrowana, a linkowana zawartość nie, IE wydaje ostrzeżenie o zawartości mieszanej . Powodem jest to, że napastnik może po drodze manipulować skryptami. Więcej informacji można znaleźć pod adresem http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 .

Kampania HTTPS Everywhere z EFF sugeruje używanie protokołu HTTPS wszędzie tam, gdzie to możliwe. W dzisiejszych czasach mamy możliwość serwowania stron internetowych zawsze zaszyfrowanych.

Tylko dla kompletności. Wspomniano o tym w innym wątku:

„Dwa ukośniki” są wspólnym skrótem określenia „jaki protokół jest obecnie używany”

if (plain http environment) {
    use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'
}

Sprawdź cały wątek.

Wydaje się, że jest to obecnie dość powszechna technika. Nie ma wady, pomaga tylko ujednolicić protokół dla wszystkich zasobów na stronie, dlatego należy go używać wszędzie tam, gdzie to możliwe.