Czy poprawne jest zastąpienie http:// przez // w a?

Jest gwarantowana praca w każdej przeglądarce głównego nurtu (nie biorę pod uwagę przeglądarek z mniejszym niż 0,05% udziałem w rynku). Heck, to działa w Internet Explorer 3.0.

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

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

Definiując względne Uri ( sekcja 5.2), możesz pominąć dowolną z tych sekcji, zawsze zaczynając od lewej. W pseudo-kodzie 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;

URI, które opisujesz, nie jest schematem względny URI.

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

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

Wiele osób nazywa to względnym adresem URL protokołu.

Powoduje podwójne pobieranie plików CSS w IE 7 & 8.

Tutaj powielam odpowiedź w ukryte cechy HTML :

Użycie bezwzględnego niezależnego od protokołu Ścieżka:

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

Jeśli przeglądarka przegląda stronę w SSL przez HTTPS, wtedy zażąda zasób z protokołem https, w przeciwnym razie zażąda go za pomocą HTTP.

To zapobiega tej okropnej " tej stronie Zawiera zarówno bezpieczne, jak i niezabezpieczone Items " komunikat o błędzie w IE, utrzymanie wszystkie Twoje żądania dotyczące aktywów w ramach to samo protokół.

Uwaga: w przypadku stosowania na <link> lub @ import dla arkusza stylów, IE7 i IE8 pobierz plik dwa razy . Wszystkie inne zastosowania są jednak w porządku.

Jest całkowicie słuszne, aby pominąć protokół. Specyfikacja URL była o tym bardzo jasna od lat, a ja jeszcze nie znalazłem przeglądarki, która tego nie rozumie. Nie wiem, dlaczego ta technika nie jest lepiej znana; jest to idealne rozwiązanie ciernistego problemu przekraczania granic HTTP / HTTPS. Więcej tutaj: Http-https przejścia i względne adresy URL

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

Dorzuć to do miksu, jeśli rozwijasz się na lokalnym serwerze, może to nie zadziałać. Musisz określić schemat, w przeciwnym razie przeglądarka może założyć, że src="//cdn.example.com/js_file.js" to src="file://cdn.example.com/js_file.js", co się zepsuje, ponieważ nie hostujesz tego zasobu lokalnie.

Prawdopodobnie zawsze starałbyś się znaleźć rozwiązanie, które działa na wszystkich Twoich środowiskach z jak najmniejszą ilością potrzebnych modyfikacji.

Rozwiązaniem używanym przez HTML5Boilerplate {[12] } jest posiadanie awaryjnego powrotu, gdy zasób nie jest ładowany poprawnie, ale działa to tylko wtedy, gdy włączysz sprawdzenie:

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

UPDATE: 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 adresów URL związanych z protokołem, zobacz [tutaj] [3].

Po odwołaniu gnud, RFC 3986 sekcja 5.2 mówi:

Jeśli element programu jest zdefiniowany, wskazując, że odniesienie zaczyna się od nazwy schematu, następnie Referencja jest interpretowana jako absolutny URI i koniec. W Przeciwnym Razie, schemat Uri odniesienia jest dziedziczona z bazowego komponentu Uri.

Więc // jest poprawne: -)

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

(edit: Oops, moje odniesienie do RFC było nieaktualne).

[1]}jest rzeczywiście poprawna, jak stwierdziły inne odpowiedzi. Należy jednak pamiętać, że niektóre Web crawlery uruchomią dla nich 404, żądając ich na serwerze, jak gdyby lokalny adres URL. (Pomijają podwójny Ukośnik i traktują go jako pojedynczy ukośnik).

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

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 okresów w Uri, musisz zwiększ swoistość lub skończy się przekierowaniem tych stron do nieistniejących domen.

Jest to również dość masywny regex, który działa dla każdego zapytania - moim zdaniem warto karać niezgodne przeglądarki 404 za (niewielki) hit wydajności w większości zgodnych przeglądarek.

Widzimy 404 błędy w naszych logach podczas korzystania z //somedomain.com jako odniesienia do plików JS.

Odniesienia, które powodują, że 404 wychodzą tak: ref:

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

404 zapytanie:

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

Ponieważ pojawiają się one regularnie w logach naszych serwerów internetowych, można śmiało powiedzieć, że: wszystkie przeglądarki i boty nie honorują sekcji 4.2 RFC 3986. Najbezpieczniejszym zakładem jest włączenie protokołu w miarę możliwości.

Wzór, który widzę na html5-boilerplate to:

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

Działa płynnie na różnych systemach, takich jak http, https, file.

Jako że twoim przykładem jest połączenie z zewnętrzną domeną, jeśli używasz HTTPS, powinieneś sprawdzić, czy zewnętrzna domena jest również skonfigurowana 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 oddzielnych folderach). Dla CDN nie powinno to być problemem, ale dla każdej innej strony internetowej może być.

Na marginesie, testowane podczas aktualizacji starej strony internetowej, a także działa w url = część odświeżania META.