URL에서 프로토콜을 상속하기 위해 선행 이중 슬래시를 사용하는 데 단점이 있습니까? 즉 src =“// domain.com”


148

외부 도메인에서 이미지를로드하는 스타일 시트가 있으며 현재 URL을 기반으로 보안 주문 페이지의 https : // 및 다른 페이지의 http : //에서로드해야합니다. 이중 슬래시로 URL을 시작하면 현재 프로토콜이 상속됩니다. 모든 브라우저가이 기술을 지원합니까?

html 예 :

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

CSS 예 :

.class { background: url(//cdn.domain.com/logo.png); }

1
이 사이트를 느리게합니까 ???
TheBlackBenzKid

2
Meder가 답변에 아래에 나열된 경우를 제외하고는 이것이 성능에 영향을 미치는 이유는 없습니다.
Rob Volk

내가 무언가에 있었던 것 같습니다. 몇 달 전, 구글 개발자는 호스팅 자바 스크립트 라이브러리 페이지에서이 규칙을 사용하기 시작 developers.google.com/speed/libraries/devguide
롭 볼크에게

10
이러한 HTML 파일이 로컬로로드되면 (브라우저로 직접 열 경우) 어떻게됩니까? Firefox (이 경우 28)처럼 보이고 원격 리소스를로드하지 않습니다. HTTP는 부모 프로토콜이 아니기 때문에 이해가됩니다. 그러나 그것은 내 의견으로는 불리 할 것입니다.
박사 Jan-Philip Gehrcke

답변:


86

브라우저가 RFC 1808 섹션 4 , RFC 2396 섹션 5.2 또는 RFC 3986 섹션 5.2 를 지원하는 경우 실제로 "//"로 시작하는 참조에 페이지 URL 체계를 사용합니다.


8
모든 주요 브라우저에서 지원됩니까? (IE7, IE8, FF, Chrome, Safari)
Rob Volk

22
RFC를 설명하는 최초의 RFC 인 RFC 1808은 15 년 전에 작성되었으며 URL 참조가 웹 사이트 기능의 핵심이라는 점을 고려하면, 현재 모든 주요 브라우저가 거의 모든 브라우저를 지원한다고 말하는 것이 안전하다고 생각합니다. 그러나 확실하게 알 수있는 유일한 방법은 직접 시도해보고 어떻게되는지 확인하는 것입니다.
Remy Lebeau

2
이 질문은 비슷한 질문을하는 누군가와 관련이 있으며 전년도 RFC 1630에서 발견되었습니다 (달리 다르게 설명되었지만 여전히 문제의 형식을 허용합니다). ftp://info.cern.ch/pub/www/doc/http-spec.txt1991 년 에 시작된 문서 중 하나 라도 다른 형식으로 보관되어있을 수 있습니다.
Jon Hanna

4
"2014.12.17 : 이제 모든 사람에게 SSL을 권장하고 성능 문제가없는이 기술은 이제 반 패턴입니다. 필요한 자산이 SSL에서 사용 가능한 경우 항상 https : // 자산을 사용하십시오." (따옴표는 stackoverflow.com/a/27999789 에서 인용 )
joonas.fi 12

@ joonas.fi 그 추론은 철학적입니다. SSL은 여전히 ​​성능에 영향을 미치며 많은 응용 프로그램에서 필요하지 않습니다. 나는 그것을 사용하는 것을 선호하지만, 예를 들어 내가 배포 한 코드에서 시행하고 싶지는 않습니다.
테우스

64

link또는 @import에서 사용될 때 IE7 / IE8은 http://paulirish.com/2010/the-protocol-relative-url/에 따라 파일을 두 번 다운로드합니다 .

2014 년 업데이트 :

이제 SSL이되어 모든 사람들에게 격려성능 문제가없는 , 이 기술은 이제 안티 패턴이다 . 필요한 자산이 SSL에서 사용 가능한 경우 항상https:// 자산을 사용하십시오 .


18
IE9, FWIW에서 수정되었습니다.
EricLaw

@EricLaw는 렌더링 모드에 관계없이 IE9에서 고정되거나 표준 모드에서만 고정되어 Quirks 모드에서 여전히 고장입니까?
scunliffe

나는 이것이 lookahead 스캐너의 모든 모드에서 수정되었다는 것에 거의 긍정적입니다. 어딘가에서 본 적이 있습니까?
EricLaw

SSL은 확실히 수행 성능에 영향을 줄. EFF는 서버-서버 인터페이스를 작성하지 않으며 다른 사이트에는 기술 전문가가 거의 없습니다. 또한 웹 사이트 공급 업체가 이러한 제한을 시행한다고 가정하는 것은 반 패턴입니다. 따라서 사람들은 CSS를 작성하고 자바 스크립트 애플리케이션은 프로토콜 질문에 의존해서는 안됩니다.
테우스

63

웹 페이지 컨텍스트 외부에서 URL을 볼 경우 단점이 있습니다. 예를 들어 전자 메일 클라이언트 (예 : Outlook)에있는 전자 메일 메시지에는 사실상 URL이 없으며 프로토콜 기준 URL이 포함 된 메시지를 볼 때 프로토콜 컨텍스트가 전혀 없습니다 (메시지 자체는 독립적 임) POP3, IMAP, Exchange, uucp 등 무엇이든 가져 오기 위해 사용 된 프로토콜) URL에 상대적인 프로토콜이 없습니다. 누락 된 프로토콜 핸들러가 제공 될 때 이메일 클라이언트와의 호환성을 조사하지 않았습니다. 대부분의 경우 http를 추측 할 것입니다. Apple Mail은 프로토콜없이 URL 입력을 거부합니다. 컨텍스트가 비슷하지 않기 때문에 상대 URL이 전자 메일에서 작동하지 않는 방식과 유사합니다.

트윗, SMS 메시지, Word 문서 등과 같은 다른 비 HTTP 컨텍스트에서도 유사한 문제가 발생할 수 있습니다.

더 일반적인 설명은 익명의 프로토콜 URL이 분리되어 작동 할 수 없다는 것입니다. 관련 컨텍스트 가 있어야합니다 . 일반적인 웹 페이지에서는 이런 방식으로 스크립트 라이브러리를 가져 오는 것이 좋지만 모든 외부 링크는 항상 프로토콜을 지정해야합니다. 하나의 간단한 테스트를 시도했습니다. 내가 시도한 모든 브라우저에서 //stackoverflow.com매핑 file:///stackoverflow.com되므로 실제로 는 작동하지 않습니다.


5
이것은 정말 좋은 지적입니다. 어제 밤에 잠들었을 때 실제로 이것에 대해 생각하고있었습니다. 또 다른 문제는 https또는 http버전이 실제로 사용 가능하지 않을 수 있다는 것입니다. 항상 있다고 가정 할 수는 없습니다.
웨슬리 머치

1
브라우저 밖에서 당신은 스스로 할 수 있습니다. 전자 메일이나 다른 클라이언트가 javascript 또는 CSS 등에 대해 알고 있다면 아무 말도하지 않습니다. 따라서 상대 URL에 대해 대략적인 근거가 있습니까?
chris

바보 같은 점이 아닙니다. 많은 전자 메일 클라이언트는 JS를 지원하며로로드 할 때 브라우저가 확실히 할 수 있습니다 file://. 사소한 사용 사례이지만, 등장 할 때 중요합니다.
Jun-Dai Bates-Kobashigawa

내가 할 지정하는 방법이 있었다하고자하는 현재의 URL에 https가 아닌, 사용 HTTP가있는 경우 HTTPS 사용 , 지정하기보다는 현재 페이지가로드 된 것과 같은 프로토콜 사용을 효과적으로 무엇인가하는 //것입니다.
Jun-Dai Bates-Kobashigawa

2
eg를 지정 <base href="https://www.google.com">하면 웹 측 외부의 컨텐츠를 볼 수 있습니다. 하나 <img src="//www.google.com/images/srpr/logo11w.png">또는<img src="images/srpr/logo11w.png">
지그재그

3

그 이유는 휴대용 웹 페이지를 제공하기위한 것일 수 있습니다. 외부 페이지가 암호화되어 전송되지 않은 경우 (http) 링크 된 스크립트를 암호화해야하는 이유는 무엇입니까? 이것은 불필요한 성능 손실로 보입니다. 외부 페이지가 안전하게 암호화 된 (https) 경우 링크 된 컨텐츠도 암호화되어야합니다. 페이지가 암호화되어 있으면 연결된 콘텐츠가 아닌 IE에서 혼합 콘텐츠 경고를 표시 하는 것 같습니다 . 공격자가 도중에 스크립트를 조작 할 수 있기 때문입니다. 자세한 내용은 http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 을 참조하십시오 .

EFF 의 HTTPS Everywhere 캠페인은 가능할 때마다 https를 사용하도록 제안합니다. 요즘에는 항상 암호화 된 웹 페이지를 제공 할 수있는 서버 용량이 있습니다.



-2

지금은 매우 일반적인 기술인 것 같습니다. 단점은 없으며 페이지의 모든 자산에 대한 프로토콜을 통합하는 데 도움이되므로 가능한 모든 곳에서 사용해야합니다.

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