Czy mogę zmienić wszystkie moje http: // linki na po prostu //?

240

Dave Ward mówi:

Nie jest to dokładnie lekka interpretacja, ale sekcja 4.2 RFC 3986 zapewnia w pełni kwalifikowane adresy URL, które całkowicie pomijają protokół (HTTP lub HTTPS). Gdy protokół URL zostanie pominięty, przeglądarka używa zamiast tego protokołu dokumentu bazowego.

Mówiąc prościej, te „bez protokołu” adresy URL pozwalają, aby taki odnośnik działał w każdej przeglądarce, w której wypróbujesz:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Na początku wygląda dziwnie, ale ten „bez protokołu” adres URL jest najlepszym sposobem na odwołanie się do treści stron trzecich, które są dostępne zarówno przez HTTP, jak i HTTPS.

To z pewnością rozwiązałoby wiele błędów o mieszanej zawartości, które widzimy na stronach HTTP - zakładając, że nasze zasoby są dostępne zarówno przez HTTP, jak i HTTPS.

Czy to jest całkowicie kompatybilne z różnymi przeglądarkami? Czy są jakieś inne zastrzeżenia?

http  url  https  protocol-relative 
— płatny kujon
źródło
Czytałem o tej technice na blogu IE jakiś czas temu. Ale kiedy spróbowałem, nie działało to całkiem dobrze. Jeśli moja witryna była obsługiwana za pomocą HTTPS, przeglądarka (Chrome) nadal używa HTTP dla adresów URL bez protokołu.
— Christopher Ramírez,
10
OSTRZEŻENIE: pamiętaj, aby NIGDY nie używać schematów URI w przekierowaniach HTTP 3xx !! Nagłówki HTTP nie są zgodne z tym formatem adresu URL. Jeśli musisz przekierować w zależności od schematu, użyj mod_rewrite lub podobnego.
— user2596282
1
@ user2596282 Eksperymentowanie we współczesnych wersjach Chrome i Firefoxa nie zgadza się z tobą, podobnie jak (wciąż w wersji roboczej) wersja HTTP 1.1. specyfikacja zdefiniowana przez grupę roboczą HTTPbis (patrz svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Być może jednak to, co mówisz, dotyczy niektórych przeglądarek; czy znasz jakieś awarie adresów URL zależnych od protokołu w nagłówkach lokalizacji?
— Mark Amery
— Álvaro González
Nie używaj ich, są brzydkie i zbędne.
— IllidanS4 chce, aby Monica wróciła

Odpowiedzi:

204

Dokładnie przetestowałem to przed publikacją. Ze wszystkich przeglądarek dostępnych do testowania na Browsershots mogłem znaleźć tylko taką, która nie obsługiwała poprawnie względnego adresu URL protokołu: niejasna przeglądarka * nix o nazwie Dillo .

Są dwie wady, o których otrzymałem opinię:

  1. Adresy bez protokołu mogą nie działać zgodnie z oczekiwaniami po „otwarciu” pliku lokalnego w przeglądarce, ponieważ podstawowym protokołem strony będzie plik: ///. Zwłaszcza gdy używasz adresu URL bez protokołu dla zewnętrznego zasobu, takiego jak zasób hostowany przez CDN. Używanie lokalnego serwera WWW, takiego jak Apache lub IIS, do testowania adresów http: // localhost adresy działa jednak dobrze.
  2. Najwyraźniej istnieje co najmniej jedna aplikacja czytnika kanałów iPhone'a, która nie obsługuje poprawnie adresów URL bez protokołu. Nie wiem, który z nich ma problem ani jak popularny. W przypadku hostingu pliku JavaScript nie jest to duży problem, ponieważ czytniki RSS i tak zwykle ignorują treść JavaScript. Jednak może to być problem, jeśli używasz tych adresów URL do multimediów, takich jak obrazy w treści, które muszą być syndykowane za pośrednictwem RSS (chociaż ta aplikacja z pojedynczym czytnikiem na jednej platformie prawdopodobnie ma bardzo niewielką liczbę czytelników).
— Dave Ward
źródło
33
Podczas gdy IE7 / 8 dobrze radzi sobie z adresami URL zależnymi od protokołu (zwanymi także schematami URI bez schematu), kiedy arkusze stylów są określone za pomocą takich adresów URL, pobierze je dwukrotnie . (Tak mówi Steve Souders )
— lucasrizoli
3
Zauważyłem, że IE6 próbuje przekonwertować identyfikator URI na względny (tj. Usunąć jeden z wiodących ukośników). To jest w linkelemencie. Na przykład podczas określania //fonts.googleapis.com/css?family=Rokkitt:400,700IE6 próbuje załadować http://mysite.com/fonts.googleapis.com/css/<...>. Nie zbyt dobrze!
— CBono
2
Znalazłem z moich dzienników instancje, które wydają się być robotami-pająkami sieciowymi (nieznane źródło), które próbują korzystać z łączy bez protokołu i również nie obsługują ich poprawnie.
— Kzqai
3
Dużo tego widziałem w moich dziennikach, niezwiązanych z adresami URL bez protokołu. Wiele z tych pająków jest po prostu bardzo źle napisanych.
— Dave Ward
11
Ważne jest, aby zrozumieć, że te adresy są nie od protokołu mniej , ale od protokołu względne . Pobierają protokół ze swojego kontekstu i bez kontekstu będą działać jak adresy URL plików w większości przeglądarek, co oznacza, że ​​włamują się, że nie ładują zamierzonej treści. Chociaż będą działać po dostarczeniu przez HTTP, przekonasz się, że jeśli zapiszesz stronę i załadujesz dokładnie ten sam kod HTML z pliku lokalnego, to nie zadziała, ponieważ kontekst jest inny. Jedynymi kontekstami, w których powinieneś ich używać, są http vs. https.
— Synchro,
37

Pytanie, czy można zmienić wszystkie linki na zależne od protokołu, może być dyskusyjne, biorąc pod uwagę, czy należy to zrobić. Według Paula Irisha :

2014.12.17: Teraz, gdy protokół SSL jest promowany dla 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 zasobu https: // .

— Ohad Schneider
źródło
Myślałem dokładnie tak samo. Jaki jest sens pobierania zewnętrznego zasobu przez http, jeśli jest on również dostępny przez https - nawet jeśli główna strona używa http (co nie powinno, ale to inny temat).
— joonas.fi
1
@ joonas.fi jedyne, o czym mogę myśleć, to unikanie mieszanych ostrzeżeń HTTP / HTTPS, które mogą być generowane przez niektóre przeglądarki
— Ohad Schneider
3
Ostrzeżenia @Ohad_Schneider są wyzwalane tylko wtedy, gdy dokument jest ładowany przez bezpieczne (https), ale zasoby przez niezabezpieczone (http). Sugerowałem, że zawsze możesz ładować zasoby w bezpieczny sposób, nawet jeśli dokument jest ładowany w sposób niezabezpieczony. Nie ma ostrzeżenia i nie ma powodu, aby nie używać bezpiecznego, przez co cały „adres URL związany z protokołem” jest niepotrzebny.
— joonas.fi
1
@Ohad_Schneider, oh przepraszam, myślę, że źle zinterpretowałem to, co mówiłeś. Ładowanie zasobów przez https, gdy dokument kończy się przez http, nie powinien powodować żadnych ostrzeżeń. Ale ładowanie zasobów przez http, gdy dokument kończy się https, robi (i prawdopodobnie jest domyślnie zablokowany, przynajmniej w Chrome). Czy miałeś na myśli przypadek, w którym wyświetlasz witrynę za pośrednictwem protokołu https, a zasoby zewnętrzne są dostępne tylko pod adresem http? Tak, to może być problem, ale nie sądzę, że istnieje jakakolwiek poważna usługa strony trzeciej, która nie obsługuje ich treści przez https, bo inaczej i tak powinni przestać działać. :)
— joonas.fi
@ joonas.fi Wut? O_o Jeśli ktoś ma adres URL strony (wtedy) protokołu HTTPS, to nie pomoże rozwiązać problemów z uzyskaniem zasobów innych firm przez HTTP - nie ma mowy. W każdym razie lepiej nie mieć tego czysto zielonego logo SSL na stronie HTTPS, niż oddać go z powrotem HTTP tylko dlatego, że strony trzecie nie obsługują jeszcze HTTPS.
— poige
15

Tak, odniesienia do ścieżki sieciowej zostały już określone w RFC 1808 i powinny działać ze wszystkimi przeglądarkami.

— Gumbo
źródło
11
Jest nawet zalecane i stosowane w kodzie HTML5: html5boilerplate.com
— Felipe Lima
1
odrobina Tak, nie odpowiadasz Tak na „Czy są jeszcze jakieś zastrzeżenia?” ? ;)
— Caspar Kleijne
2
@Caspar Kleijne: Wyjaśniłem „Tak” resztą zdania.
— Gumbo
1
Casper, Gumbo odpowiadał na dwa zadane pytania: „Czy to jest całkowicie kompatybilne z różnymi przeglądarkami? Czy są jakieś inne zastrzeżenia?” Tak, jest odpowiedzią na pierwsze pytanie.
— Darren Griffith,
4

Czy to jest całkowicie kompatybilne z różnymi przeglądarkami? Czy są jakieś inne zastrzeżenia?

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

Tutaj także opublikowałem tę odpowiedź .

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 .

— bg17aw
źródło
1

Nie miałem tych problemów podczas używania: //domain.com - ale musisz dodać dwukropek na początku. Yoast już dawno o tym napisał. Ale zagubił się w stosie postów na blogu.

— użytkownik1431784
źródło
głosuj w dół za brak podania, gdzie przydatne jest dodatkowe: Wszędzie, gdzie przypadkowo zostawiłem „:”, zrywałem link
— rob
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.