모든 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.