요약

  • RFC 2397은 작은 “즉시(immediate)” 페이로드를 위한data:스킴을 정의했으며, 선택적 미디어 타입, 선택적;base64플래그, 그리고 데이터 앞의 쉼표를 사용했습니다.
  • 바이트를 URL 자체에 실어 나르는 방식으로, 이 스킴은 결정적인 통제 지점을 원격 검색 경로에서 로컬 URL 소비자, 미디어 핸들러, 버퍼 경계로 옮겼습니다.

대부분의 주소는 여정을 약속합니다. 클라이언트는 로케이터를 읽고, 다른 어딘가에 있는 무언가에 접촉하며, 그 대가로 표현을 받아 돌아옵니다. RFC 2397은 더 좁은 방식을 기술했습니다. 주소가 표현을 그 자체에 실고 다닐 수 있다는 것입니다. 그 문법은data:[<mediatype>][;base64],<data>처럼 한 줄에 담길 만큼 간결했지만, 그 표기법이 가져온 아키텍처상의 변화는 훨씬 컸습니다.

이 RFC는 이를 “즉시 주소 지정(immediate addressing)”이라고 불렀습니다. 이 단어가 중요합니다.data:URL은 쉼표 뒤에 숨어 있는 작은 서버를 가리키지 않습니다. 내장된 항목 자체에 대해서는 참조할 두 번째 위치가 존재하지 않습니다. 소비자는 선언부와 페이로드를 분리한 뒤, 미디어 타입에 따라 결과 옥텟을 해석합니다. 주소와 화물은 하나의 직렬화된 객체가 된 것입니다.

그 객체에도 규칙이 있습니다. 미디어 타입이 없으면text/plain;charset=US-ASCII가 기본값이 됩니다.text/plain축약형을 생략한 채 문자셋만 제공할 수도 있습니다. 맨해튼 토큰;base64는 base64를 선택합니다. 등호가 없기 때문에 이것은 일반적인 콘텐츠 타입 매개변수가 아닙니다. 이 플래그가 없으면 URL 안전 문자로 표현된 옥텟은 직접 나타날 수 있고, 나머지 옥텟은%xx이스케이프를 사용합니다. Base64는 표현 선택이지 암호화, 인증, 권한 부여가 아닙니다.

이 스킴은 익숙한 편의 기능도 거부합니다. RFC 2397은 상대 형식을 정의하지 않습니다. 기준 URL이 완성할 것이 없습니다. 정의 행위 자체가 이미 그 안에 있기 때문입니다. 문자열이 어떤 데이터가 뒤따르는지 말한 다음 그것을 공급하기 때문입니다. 이 경계는data:를 문서를 이동 가능하게 만든 상대 참조 메커니즘과 구별합니다. 하나는 문맥에서 주소를 빌려 오고, 다른 하나는 자기 자신의 바이트를 실어 나릅니다.

명세는 작음을 거듭 강조합니다. HTML 2.0 속성을 둘러싼 SGML 한도를 인용하면서, 하나의 속성 값 리터럴은 1,024자, 태그 안 모든 속성 값은 2,100자, 태그 자체는 2,100자로 제한되었습니다. 인라인 GIF는 유용성의 가장자리에 가까운 것으로 묘사됩니다. 이 수치들은 보편적 용량 보장이 아니라 주변 포맷의 속성이었습니다. 이 수치들은 더 오래 지속되는 한 가지를 보여줍니다. 문법이 허용하는 수열을 호스트 문법, 할당 전략 또는 구현이 합리적으로 흡수하지 못할 수 있다는 점입니다.

이 구별은 보안 절에서 더 분명해집니다. 방화벽 프록시는 허용되지 않는 미디어 타입을 원격지에서 검색하는 것을 거부할 수 있습니다. 하지만 로컬에서 처리되는 로케이터 안에 이미 밀봉되어 도착한 바이트를 단속하는 것은 더 어렵습니다. 따라서 RFC 2397은 책임을 애플리케이션에 둡니다. 선언된 타입이 구성에서 금지된data:값을 해석해서는 안 됩니다. 관련 게이트는 바이트를 동작으로 바꾸는 구성 요소입니다.

같은 절은 매우 긴 값의 효과가 알려지지 않았으며, 데이터가 할당된 버퍼를 초과하면 소프트웨어가 비합리적으로 동작할 수 있다고 경고했습니다. 이 경고는 정책과 용량을 연결합니다. 소비자는 미디어 타입이 실행될 수 있는지와 입력을 안전하게 처리할 수 있는지 둘 다 결정해야 합니다. 내장된 항목을 결코 가져오지 않는 네트워크 경로는 소비자를 대신해 어느 쪽도 결정할 수 없습니다.

문서의 역사는 이것이 추상적인 연습이 아니었음을 보여줍니다. 이 아이디어는 1995년 8월로 거슬러 올라가며, VRML, HTML 내장 데이터 제안, 상용 제품, Java 및 ActiveX 객체의 매개변수에 나타났습니다. 문법은 그 과정에서 다듬어졌습니다. 미디어 타입 생략이 가능해졌고, base64 표시자는 더 엄격해졌으며, quoted-printable은 URL 이스케이프가 이미 필요한 표현을 제공한다는 이유로 제거되었습니다.

이후의 정오표도 기록의 일부이지만, 모두 동등한 지위를 갖는 것은 아닙니다. 두 건의 검증된 정정은 불가능한%fg예제를 교체하고, RFC 2396에서 가져온 프로덕션을 정의되지 않은urlchar에서uric으로 바꿉니다. 보고된 제안과 업데이트 보류 보고서는 quoted 미디어 타입 매개변수와 구분 기호를 둘러싼 모호성을 드러냅니다. 이들은 검증된 대체 텍스트가 아니라 가장자리에 대한 경고입니다. 모든 “URL”을 “URI”로 바꾸자는 제안은 원래 용어가 역사적으로 옳았기 때문에 거부되었습니다.

따라서 RFC 2397의 오래된 교훈은 참신함이 아니라 통제에 관한 것입니다. 주소가 자신이 가리키는 것을 담고 있을 때, 통제가 사라지지 않습니다. 통제는 옮겨 갑니다. 파서는 메타데이터가 어디서 끝나는지 선택합니다. 디코더는 옥텟을 재구성합니다. 미디어 핸들러는 그것이 무엇을 의미하는지 결정합니다. 애플리케이션은 무엇을 허용할지 결정합니다. 버퍼는 무엇을 견딜 수 있는지 결정합니다. 가장 짧은 검색 경로는 로컬 규율이 가장 중요한 경로이기도 합니다.

출처