Czy istnieje jakaś przewaga za używanie wiodącego podwójnego ukośnika do dziedziczenia protokołu w adresie URL? tj. src = "// domena.com"

Question

Mam arkusz stylów, który ładuje obrazy z domeny zewnętrznej i potrzebuję go załadować z https: // z bezpiecznych stron zamówień i http: // z innych stron, na podstawie obecny adres URL. Zauważyłem, że uruchomienie adresu URL z podwójnym ukośnikiem dziedziczy bieżący 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); } 

Answer 1

Jeśli przeglądarka obsługuje RFC 1808 Section 4, RFC 2396 Section 5.2 lub RFC 3986 Section 5.2, to będzie rzeczywiście użyć schematu URL strony dla referencji, które zaczynają się od " // ".

Answer 2

Przy stosowaniu na link lub @import, IE7/IE8 będzie pobrać plik dwa razy http://paulirish.com/2010/the-protocol-relative-url/

aktualizacji od 2014:

Teraz SSL jest encouraged for everyone i doesn’t have performance concerns, technika ta jest obecnie anty-wzór. Jeśli wymagany zasób jest dostępny w protokole SSL, zawsze zawsze korzysta z zasobu https://.

Answer 3

Jedna z wad występuje, gdy adresy URL są wyświetlane poza kontekstem strony internetowej. Na przykład wiadomość e-mail umieszczona w kliencie poczty e-mail (powiedzmy Outlook) nie zawiera adresu URL, a podczas przeglądania wiadomości zawierającej adres URL protokołu nie ma w ogóle oczywistego kontekstu protokołu (sama wiadomość jest niezależna) protokołu używanego do pobierania, niezależnie od tego, czy jest to POP3, IMAP, Exchange, uucp czy cokolwiek innego), więc adres URL nie ma protokołu, z którym należy się względnie. Nie badałem kompatybilności z klientami poczty e-mail, aby zobaczyć, co robią, gdy prezentowane są z brakującym narzędziem obsługi protokołu - domyślam się, że większość zgadnie na http. Firma Apple Mail odmawia podania 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 w tweety, wiadomości SMS, dokumentów Worda itp

Im bardziej ogólne wyjaśnienie, że anonimowe adresy protokołu nie może pracować w odosobnieniu; tam musi być odpowiednim kontekstem. Na typowej stronie internetowej tak dobrze jest wciągnąć bibliotekę skryptów w ten sposób, ale wszelkie linki zewnętrzne powinny zawsze określać protokół. Spróbowałem jednego prostego testu: //stackoverflow.com map do file:///stackoverflow.com we wszystkich przeglądarkach, które wypróbowałem, więc one naprawdę nie działają same.

Answer 4

Przyczyną może być dostarczenie przenośnych stron internetowych. Jeśli strona zewnętrzna nie jest transportowana w postaci zaszyfrowanej (http), dlaczego połączone skrypty powinny być szyfrowane? Wydaje się to być niepotrzebną utratą wydajności. W przypadku, gdy strona zewnętrzna jest bezpiecznie transportowana w postaci zaszyfrowanej (https), to połączona treść powinna być również zaszyfrowana. Jeśli strona jest zaszyfrowana, połączona treść nie, IE wydaje się wydawać ostrzeżenie Mixed Content. Powodem jest to, że atakujący może manipulować skryptami po drodze. Zobacz dłuższą dyskusję na stronie http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1.

Kampania z EFF w wersji HTTPS Everywhere sugeruje korzystanie z https, gdy tylko jest to możliwe.Mamy obecnie pojemność serwera do obsługi stron internetowych zawsze zaszyfrowanych.

Answer 5

Tylko dla kompletności. To zostało wspomniane w innym wątku:

'The two forward slashes are a common shorthand for whatever protocol is being used right'

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

proszę sprawdzić pełną wątek.

Answer 6

Wydaje się być dość powszechną techniką. Nie ma minusów, pomaga tylko ujednolicić protokół dla wszystkich zasobów na stronie, więc powinien być używany wszędzie tam, gdzie to możliwe.