모든 http : // 링크를 // //로 변경할 수 있습니까?


240

데이브 워드 는 말합니다.

정확하게 읽는 것은 아니지만 RFC 3986의 섹션 4.2는 프로토콜 (HTTP 또는 HTTPS)을 완전히 생략하는 정규화 된 URL을 제공합니다. URL의 프로토콜이 생략되면 브라우저는 기본 문서의 프로토콜을 대신 사용합니다.

간단히 말해, 이러한 "프로토콜이없는"URL을 사용하면 시도 할 모든 브라우저에서 다음과 같은 참조가 작동합니다.

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

처음에는 이상해 보이지만이 "프로토콜없는"URL은 HTTP 및 HTTPS를 통해 사용 가능한 타사 컨텐츠를 참조하는 가장 좋은 방법입니다.

이렇게하면 자산이 HTTP와 HTTPS를 통해 사용 가능하다는 가정하에 HTTP 페이지에서 발생하는 많은 혼합 컨텐츠 오류를 확실히 해결할 수 있습니다.

이 브라우저는 완전히 크로스 브라우저와 호환됩니까? 다른 경고가 있습니까?


얼마 전에 IE 블로그에서이 기술에 대해 읽었습니다. 그러나 내가 시도했을 때 제대로 작동하지 않습니다. 내 사이트에 HTTPS가 제공되는 경우 브라우저 (Chrome)는 여전히 프로토콜이없는 URL에 HTTP를 사용하고있었습니다.
— Christopher Ramírez 2016 년

10
경고 : HTTP 3xx 리디렉션에서 사용자 스키마없는 URI를 절대로 잊지 마십시오 !! HTTP 헤더는이 URL 형식과 호환되지 않습니다. 구성표에 따라 리디렉션해야하는 경우 mod_rewrite 또는 이와 유사한 것을 사용하십시오.
— user2596282

1
@ user2596282 최신 버전의 Chrome 및 Firefox 실험에서 HTTP 1.1에 대한 (아직 초안) 개정판과 마찬가지로 동의하지 않습니다. HTTPbis 작업 그룹에 의해 정의 된 사양 ( svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… 참조 ). 아마도 여러분이 말하는 것은 일부 브라우저에 해당됩니다. 특히 위치 헤더의 프로토콜 기준 URL에서 실패한 것을 알고 있습니까?
— Mark Amery


그것들을 사용하지 마십시오. 추악하고 중복됩니다.
— IllidanS4는 Monica가

답변:


204

게시하기 전에 철저히 테스트했습니다. Browsershots 에서 테스트 할 수있는 모든 브라우저 중에서 프로토콜 상대 URL을 올바르게 처리하지 못하는 브라우저 만 찾을 수 있습니다 : Dillo 라는 모호한 * nix 브라우저 .

피드백을받은 두 가지 단점이 있습니다.

  1. 페이지의 기본 프로토콜은 file : ///이므로 브라우저에서 로컬 파일을 "열 때"프로토콜이없는 URL이 예상대로 작동하지 않을 수 있습니다. 특히 CDN 호스팅 자산과 같은 외부 리소스에 프로토콜이없는 URL을 사용하는 경우. Apache 또는 IIS와 같은 로컬 웹 서버를 사용하여 http : // localhost 주소 를 테스트하는 것이 좋습니다.
  2. 프로토콜이없는 URL을 올바르게 처리하지 않는 iPhone 피드 리더 앱이 하나 이상있는 것 같습니다. 어떤 문제가 있는지 또는 얼마나 인기가 있는지 잘 모르겠습니다. JavaScript 파일 호스팅의 경우 RSS 리더는 일반적으로 JavaScript 내용을 무시하므로 큰 문제는 아닙니다. 그러나 RSS를 통해 신디케이트해야하는 콘텐츠 내의 이미지와 같은 미디어에이 URL을 사용하는 경우 문제가 될 수 있습니다 (단일 플랫폼의이 단일 판독기 앱은 매우 적은 수의 판독기를 차지할 수 있습니다).

33
IE7 / 8은 대부분의 경우 프로토콜 기준 URL (일명 스키마없는 URI)을 잘 처리하지만 이러한 URL로 스타일 시트를 지정하면 두 번 다운로드됩니다 . (따라서 Steve
— Souders가

3
IE6이 URI를 상대 URL로 변환하려고 시도합니다 (예 : 선행 슬래시 중 하나 제거). 이것은 link요소에 있습니다. 예를 들어,을 지정할 때 //fonts.googleapis.com/css?family=Rokkitt:400,700IE6는로드를 시도합니다 http://mysite.com/fonts.googleapis.com/css/<...>. 너무 좋지 않아!
— CBono

2
프로토콜 로그 링크를 사용하려고 시도하고 제대로 처리하지 않는 웹 스파이더 로봇 (소스 알 수 없음)으로 보이는 로그 인스턴스를 찾았습니다.
— Kzqai

3
프로토콜이없는 URL과 관련이없는 로그에서 많은 것을 보았습니다. 그 거미들 중 상당수는 엄청나게 잘못 쓰여져 있습니다.
— Dave Ward

11
그것은 이러한 URL이라는 것을 이해하는 것이 중요 하지 프로토콜 - 덜 하지만, 프로토콜 - 상대 . 컨텍스트에서 프로토콜을 가져오고 컨텍스트가 부족하면 대부분의 브라우저에서 파일 URL처럼 작동하므로 의도 한 내용을로드하지 않는다는 사실을 효과적으로 의미합니다. http를 통해 전달 될 때 작동하지만 페이지를 저장하고 로컬 파일에서 정확히 동일한 HTML을로드하면 컨텍스트가 다르기 때문에 해당 HTML이로드되지 않습니다. 당신이 사용해야하는 유일한 컨텍스트는 http 대 https입니다.
— Synchro

37

사람이 있는지 여부의 문제 수있는 모든 링크를 변경 한 여부의 문제 고려, 프로토콜 상대가 논쟁 할 수있다 할 수 있어야 그렇게합니다. 폴 아일랜드 에 따르면 :

2014.12.17 : 이제 모든 사람에게 SSL을 권장하고 성능에 대한 우려가 없으므로이 기술은 이제 안티 패턴입니다. 필요한 자산이 SSL에서 사용 가능한 경우 항상 https : // 자산을 사용하십시오 .


나는 똑같은 생각을하고있었습니다. 기본 사이트가 http를 사용하지 않더라도 https를 통해서도 사용 가능한 경우 http를 통해 외부 자산을 다운로드 할 때 요점은 무엇입니까 (다른 주제).
— joonas.fi

1
@ joonas.fi 내가 생각할 수있는 유일한 것은 일부 브라우저에서 생성 될 수있는 혼합 된 HTTP / HTTPS 경고를 피하는 것입니다.
— Ohad Schneider

3
@Ohad_Schneider 경고는 문서가 보안 (https)에로드되었지만 자산이 안전하지 않은 (http)에로드 된 경우에만 트리거됩니다. 내가 제안한 것은 문서가 안전하지 않은 상태로로드 된 경우에도 항상 자산을 안전하게로드 할 수 있다는 것입니다. "프로토콜 기준 URL"전체를 불필요하게하여 경고를 사용하거나 보안을 사용할 이유가 없습니다.
— joonas.fi

1
@Ohad_Schneider 아 죄송합니다, 당신이 말한 것을 잘못 해석했다고 생각합니다. 문서가 http 위에있을 때 https를 통해 자산을로드하면 경고가 발생하지 않아야합니다. 그러나 문서가 https 위에있을 때 http를 통해 자산을로드하면 (적어도 Chrome에서는 기본적으로 차단 될 수 있습니다). https를 통해 사이트를 제공하고 외부 자산이 http에서만 제공되는 경우를 언급하고 있습니까? 예, 그것은 문제가 될 수 있지만 https를 통해 콘텐츠를 제공하지 않는 심각한 타사 서비스가 있거나 그렇지 않으면 비즈니스를 중단해야한다고 생각하지 않습니다. :)
— joonas.fi

@ joonas.fi Wut? O_o 누군가가 HTTPS로 연결된 사이트 (다음) 프로토콜 상대 URL을 가지고 있다면 HTTP를 통해 타사 자산을 얻는 데 도움이되지 않습니다. 어쨌든 HTTPS 페이지에 깨끗한 녹색 SSL 로고가없는 것이 타사가 HTTPS를 아직 지원하지 않기 때문에 다시 HTTP를 제공하는 것보다 낫습니다.
— poige


15

예, 네트워크 경로 참조는 이미 RFC 1808에 지정되어 있으며 모든 브라우저에서 작동해야합니다.


11
그것은 HTML5 상용구 코드에서 권장되고 사용됩니다 : html5boilerplate.com
— Felipe Lima

1
그렇습니다. "다른 경고가 있습니까?"라고 대답하지 않습니다. ? ;)
— Caspar Kleijne

2
@Caspar Kleijne : 나머지 문장과 함께 예를 설명했습니다.
— Gumbo

1
캐스퍼, 검보는 실제로 두 가지 질문에 대답했습니다. "이것은 브라우저 간 완벽하게 호환됩니까? 다른 경고가 있습니까?" 예는 첫 번째 질문에 대한 답입니다.
— 대런 그리피스

4

이 브라우저는 완전히 크로스 브라우저와 호환됩니까? 다른 경고가 있습니까?

로컬 서버에서 개발하는 경우 믹스에 이것을 던져 넣으면 작동하지 않을 수 있습니다. 당신은 그렇지 않으면 브라우저가 있다고 가정 할 수있다하는 방식을 지정할 필요가 src="//cdn.example.com/js_file.js"있습니다 src="file://cdn.example.com/js_file.js"로컬이 리소스를 호스팅하지 않는 때문에 휴식 것이다.

Microsoft Internet Explorer는 이것에 특히 민감한 것 같습니다.이 질문을 참조하십시오 : localhost (WAMP)의 Internet Explorer에서 jQuery를로드 할 수 없습니다

아마도 최소한의 수정만으로도 모든 환경에서 작동하는 솔루션을 찾으려고 노력할 것입니다.

HTML5Boilerplate에서 사용하는 솔루션 은 리소스가 올바르게로드되지 않은 경우 폴백을 수행하는 것이지만 확인을 통합 한 경우에만 작동합니다.

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

이 답변도 여기에 게시했습니다 .

업데이트 : HTML5Boilerplate은 이제 <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">프로토콜 상대 URL을 더 이상 사용하지 않기로 결정한 후 사용합니다 ( here 참조) .


1

: //domain.com을 사용할 때 이러한 문제가 없었지만 처음에 콜론을 추가해야합니다. Yoast는 이것에 대해 한동안 글을 올렸습니다. 그러나 블로그 게시물 더미에서 길을 잃었습니다.


추가가 유용한 위치를 표시하지 않기 위해 투표하십시오. 실수로 왼쪽 도처 ":"링크 파산
— 강탈

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.