요약

  • RFC 2295는 하나의 HTTP URI에 연결된 여러 표현을 기계가 읽을 수 있는 변형 목록을 통해 드러내도록 했지만, 목록 응답 자체에는 변형 데이터가 담기지 않았습니다.
  • 선택, 검색, 표시는 별개의 단계로 남았습니다. 서버는 조건에 따라 choice 응답을 반환할 수 있고, 사용자 에이전트가 스스로 변형을 골라 가져올 수도 있었습니다.

하나의 자원이 여러 개의 답을 가질 수 있었다

1990년대 후반 웹은 이미 실용적인 불일치에 직면해 있었습니다. 하나의 자원이 HTML이나 PostScript로, 영어나 프랑스어로 존재할 수 있었고, 서로 다른 사용자 에이전트에 맞는 기능을 갖추고 있을 수도 있었습니다. 발행자는 URL을 나누어 노출하거나 한 URI 안에서 버전 간 협상을 할 수 있었습니다. 어려운 부분은 버전을 고르는 것만이 아니었습니다. 중개자, 특히 캐시도 어느 응답이 어느 요청에 속하는지 알아야 했습니다.

RFC 2295, “HTTP에서의 투명 콘텐츠 협상”은 대안을 드러내기 위한 실험적 방식을 제안했습니다. 1998년 3월의 이 메모는 버전을변형(variant)이라 불렀고, 변형 목록을 하나의 협상 가능한 자원에 묶인 기계 가독형 설명의 집합으로 규정했습니다. 이 문서의Alternates헤더는 각 후보의 URI와 미디어 타입, 언어, 원본 품질, 기능 같은 속성을 식별할 수 있었습니다. “투명”하다는 것은 원본 서버 안에 들어 있는 변형들이 외부 당사자에게 보이게 된다는 뜻이었습니다. 모든 브라우저가 자동으로 협상한다는 뜻도, 선택이 시야에서 사라진다는 뜻도 아니었습니다.

이 제안은 협상 차원을 네 가지로 명명했습니다. 미디어 타입, 문자셋, 언어, 그리고 기능(features)입니다. 기능 차원은 앞의 세 가지로 표현할 수 없는 속성, 예컨대 특정 마크업 지원이나 미디어 타입 역량을 위한 확장 지점이었습니다. 콘텐츠 인코딩—예를 들어 압축—은 이 방식에서 다섯 번째 변형 차원이 아니라 직교하는 개념이었습니다. 이 경계가 중요합니다. 이 문서는 서버가 자신의 바이트에 적용할 수 있는 모든 변환이 아니라, 어느 표현이 적절한지를 기술하려 했던 것입니다.

영수증은 하나가 아니라 셋

목록 응답은 일종의 목록화였습니다. RFC 2295는 이를 변형 목록은 반환하되 변형 데이터는 담지 않는 응답으로 정의합니다. 협상하는 사용자 에이전트는 대안들을 평가한 뒤, 변형의 URI에 대한 일반 요청으로 하나를 검색할 수 있었습니다. RFC의 예시는 이 분리를 문자 그대로 보여줍니다. 먼저 서버가 목록을 반환하고, 그다음 클라이언트가paper.1을 요청하며, 논문 자체는 두 번째 응답에서만 전달됩니다. 300 Multiple Choices 응답에는 사람이 읽을 수 있는 본문을 포함할 수도 있어, 협상하지 않는 사용자 에이전트나 독자가 수동으로 고를 수 있었습니다. 그 경우에도 목록 자체는 선택된 표현이 아니었습니다.

서버는 단순한 목록 관리원이 아니었습니다.choice 응답은 최적 변형의 표현을 반환하며 목록까지 함께 담을 수 있었습니다. 그러나 서버가 사용자 에이전트를 대신해 선택하려면 충분한 정보가 필요했고, 선택된 변형은 RFC의 URI 기반 규칙에서 인접 자원이어야 했습니다. RFC 2295와 짝을 이루는 실험적 메모인 RFC 2296은 원격 선택 알고리즘을 규정하고 “choice”를 조건부로 만들었습니다. 가용한 증거가 긍정적이고 명확한 최적 변형을 확립하지 못하거나, 자원이 인접성 조건을 충족하지 못하면 알고리즘은 목록을 대신 반환했습니다. RFC 2295는 클라이언트가 자신의 로컬 알고리즘을 적용하고, 목록이 여전히 가용할 때 다른 변형을 검색하는 것도 허용했습니다.

그래서 이 역사를 “클라이언트가 골랐다”고 말하는 것은 정확하지 않습니다. 때로 그럴 수 있었고, 때로 서버가 그랬습니다. 프로토콜은 후보 목록화, 결정 권한, 바이트를 전달하는 응답, 그리고 그 이후의 표시 행위를 분리했습니다.Negotiate는 서버의 관점에서 사용자 에이전트가 투명 협상 지원을 선언하는 신호였습니다. 기능 선언은 특정 요청이 그것을 사용했다는 영수증이 아니었습니다.

캐시는 설계의 일부였다

협상은 같은 URI가 서로 다른 표현을 내놓게 만들 수 있습니다. 캐시가 그 응답들을 혼동하면, 좋은 선택 알고리즘도 나쁜 결과를 낳습니다. 그래서 RFC 2295는 HTTP의Vary메커니즘과 엔티티 태그와 함께 작동했고, 변형 목록용 검증자를 추가했습니다. 그 규칙들은 캐시가 choice 응답에서 일반 응답을 추출하는 방법과, 선택된 자원의 위치가 협상 가능한 자원과 어떤 관계에 있는지를 기술했습니다. 캐시 정확성은 장식적인 배관이 아니라 URI 재사용을 그럴듯하게 만드는 계약의 일부였습니다.

이 설계는 비용도 드러냈습니다. 모든 요청에 모든 선호를 담아 보내는 것은 장황할 수 있어, 사용자 에이전트는 목록을 로컬에서 살펴보아야 하는 경우가 많았습니다. 그런데Accept선호는 사용자의 소프트웨어나 환경에 관한 특성을 드러낼 수 있습니다. 이 메모는 프라이버시 누출, 변형 자원의 위조된 응답, 협상으로 드러나는 보안 결함을 명시적으로 논의했습니다. 이것들은 RFC가 인식한 설계상의 관심사지지, 특정 사건이 발생했다는 증거가 아닙니다.

RFC 2295는 명시적으로실험적(Experimental)문서였고, 인터넷 표준을 규정하지 않는다고 밝혔습니다. 이 문서는 투명 메커니즘을 모든 HTTP 트랜잭션이 아니라 GET과 HEAD에 적용했습니다. 클라이언트, 서버, 캐시에 선택을 분산하면서 대안을 검사 가능하게 만든다는 야망은 사양서에서 재구성할 수 있습니다. 여기서 가용한 증거는 브라우저 지원 현황, 배포율, 사용자 성공 사례를 확립하지 못합니다. 광고된 변형이 반드시 가져와진 것은 아니고, 받은 응답이 사람이 무엇을 보았는지의 증명도 아닙니다.

출처