Зачем вообще использовать протокол-относительные URL?

Question

На Stackru часто обсуждается вопрос, что это значит:

 <script src="//cdn.example.com/somewhere/something.js"></script>

Это дает преимущество в том, что если вы обращаетесь к нему через HTTPS, вы получаете HTTPS автоматически, а не это страшное предупреждение "Небезопасные элементы на этой странице".

Но зачем вообще использовать протоколы, относящиеся к протоколу? Почему бы просто не использовать HTTPS всегда в URL CDN? В конце концов, у HTTP-страницы нет причин жаловаться, если вы решите загрузить некоторые ее части по HTTPS.

(Это более конкретно для CDN; почти все CDN имеют возможность HTTPS. В то время как ваш собственный сервер может не обязательно иметь HTTPS.)

Answer 1

По состоянию на декабрь 2014 года в блоге Пола Айриша по URL-адресам, связанным с протоколом, говорится:

2014.12.17: Теперь, когда SSL приветствуется для всех и не имеет проблем с производительностью, этот метод теперь является антишаблоном. Если нужный вам актив доступен по SSL, то всегда используйте https:// актив.

Если у вас нет особых проблем с производительностью (например, медленная сеть мобильной связи, упомянутая в ответе Закьяна), вы должны использовать https:// чтобы защитить ваших пользователей.

Answer 2

Из-за производительности. Установление HTTPS-соединения занимает намного больше времени, чем HTTP, TLS-квитирование добавляет задержку задержки до 2 RTT с. Вы можете заметить это в мобильных сетях. Поэтому лучше не использовать URL-адреса ресурсов HTTPS, если они вам не нужны.

Answer 3

Существует ряд потенциальных причин, хотя все они не особенно важны:

• Как насчет того, чтобы в следующий раз каждый бизнес с повесткой дня выдвигал новый протокол? Должны ли мы снова поменять тысячи строк? Нет, спасибо.
• HTTPS медленнее, чем HTTP той же версии
• Если какие-либо заметки, перечисленные на caniuse.com для HTTP/2, являются проблемой
• Концептуально, если сервер применяет протокол, нет никаких оснований быть конкретным в первую очередь. Агностицизм это то, что он есть. Он охватывает все ваши базы.

Answer 4

Стоит отметить, что если вы используете CSP upgrade-insecure-requests, вы можете безопасно использовать независимые от протокола URL (//example.com).

Answer 5

URL-адреса, относящиеся к протоколу, иногда нарушают JS-коды, которые пытаются определить location.protocol. Их также не понимают очень старые браузеры. Если вы разрабатываете веб-службы, которые требуют максимальной обратной совместимости (т. Е. Обслуживают важную экстренную информацию, которая может быть получена / отправлена ​​на медленных соединениях и / или старых устройствах), не используйте PRURL.