요약

  • RFC 3205는 HTTP 재사용을 상속된 동작을 함께 가져오는 설계 선택으로 보았으며, 상호운용성이나 보안을 자동으로 제공하는 지름길로 보지 않았다.
  • 그 핵심 과제는 명시성이었다. 서비스 식별, 메서드와 미디어 타입, 프록시 상호작용, 캐싱, 그리고 HTTP 오류와 애플리케이션 결과 사이의 경계를 정의하는 것이었다.

그 거래에는 또 다른 당사자가 있었다

2002년 초 무렵, HTTP는 새로운 애플리케이션 프로토콜을 위한 매력적인 도구 꾸러미를 제공했다. 개발자들이 익숙했고, 브라우저가 그것을 말할 수 있었으며, 서버와 클라이언트 라이브러리는 이미 존재했고, TLS나 익숙한 인증도 이용 가능할 수 있었다. 어떤 사이트가 이미 웹을 서비스하고 있다면, 다른 애플리케이션을 같은 기반 위에서 프로토타입하는 것이 더 저렴해 보일 수 있었다. 방화벽 통과도 장점으로 언급되곤 했다. 그 거래는 “설치된 기반을 재사용한다”는 것처럼 보였다.

RFC 3205, 즉 Keith Moore의 BCP 56은 그 덜 보이는 상대방을 설계의 일부로 만들었다. HTTP는 두 종단점이 교환하는 인코딩일 뿐이 아니었다. 하나의 요청은 클라이언트 라이브러리, 프록시, 캐시, 방화벽, NAT, 웹 서버를 거쳐 애플리케이션 코드에 이르기까지, 익숙한 필드를 각자 다르게 읽는 여러 구성 요소를 만날 수 있었다. 한 구성 요소에서 절약한 노력이 그 구성 요소들이 애플리케이션의 의미를 공유하게 만들지는 않았다.

이 문서는 의도적으로 권고였지 적합성 명세가 아니었다. 스스로 그렇게 밝히고 RFC 2119의 대문자 요구 단어를 피했다. 그 요점은 모든 애플리케이션이 HTTP를 피해야 한다는 것이 아니었다. 그 선택이 비용과 경계가 보이는 상태에서 이루어져야 한다는 것이었다. HTTP에는 지속 연결, 범위 요청, 콘텐츠 협상, 캐싱이 축적되어 있었다. 계층화된 프로토콜은 필요하지 않은 기능을 상속받은 뒤, 그것들을 걷어내는 데 노력을 쓸 수 있었다. 아주 작고 빈번한 트랜잭션에서는 TCP와 HTTP 오버헤드가 문제가 될 수 있었고, 여러 교환이 하나의 열린 세션을 재사용할 때는 지속 연결이 접속 비용을 줄일 수 있었다.

익숙한 상태 코드가 잘못된 이야기를 전할 수 있었다

어려운 사례는 반드시 기형적인 요청이 아니었다. 한 계층이 성공이라 부르는 응답을 다른 계층이 애플리케이션 실패로 이해하는 경우였다. 프록시는 새 애플리케이션을 알 필요 없이 HTTP 의미에 따라 동작할 수 있었다. 일반적인 조건에서 성공적인 응답을 캐시할 수 있었다. 중개자는 오류 본문을 대체하거나 보강할 수도 있었다. 따라서 클라이언트는 애플리케이션 의미가 낡았거나, 가려졌거나, 변경된 상태로 유효한 HTTP 응답을 받을 수 있었다.

RFC 3205는 HTTP의 요청 라인과 헤더에서 감지되는 오류를 계층화된 애플리케이션이 인코딩하는 결과와 분리했다. 애플리케이션이 본문 수준의 결과에 일반적인 200 또는 500 응답을 사용한다면, 성공적인 응답이 유해한 캐싱을 피하는 방법과 클라이언트가 변형된 오류 본문에서 살아남는 방법을 명세해야 했다. 중개자가 그런 응답을 캐시하거나 변경할 때 프로토콜이 작동할 수 없다면, 이 문서는 HTTP를 기반으로 사용하지 말 것을 권했다. 이것은 “HTTP 상태 코드는 나쁘다”는 말보다 정확하다. 위험은 HTTP의 일반적인 성공/실패 모델과 애플리케이션의 트랜잭션 모델이 어긋나는 지점에서 발생했다.

같은 경계가 미디어 타입과 메서드에도 나타났다. 콘텐츠 타입은 객체가 무엇인지 식별할 수 있었지만, 그것 자체로는 해당 객체에 대한 작업을 승인하지 않았다. 애플리케이션은 자신의 동작을 명시해야 했다. 새 HTTP 메서드를 발명하는 것이 별개의 서비스가 자체 포트나 URI 스킴을 가져야 하는지 여부를 자동으로 정해 주지도 않았다.

재사용에는 식별과 배포도 포함되었다

포트 80과http:는 이미 운영자, 소프트웨어, 사용자에게 어떤 의미를 지니고 있었다. RFC 3205는 서비스가 별도의 데이터, 코드, 프로세스 또는 트래픽 제어 요구를 갖는지 물었다. 그런 차이는 별도의 포트를 정당화할 수 있었다. 설정, 자격 증명, 프로비저닝이 다른 널리 사용되는 서비스는 그 구분을 숨기는http:라벨 대신 자체 URI 스킴이 필요할 수 있었다. 이 문서는 이를 명명의 미학이 아니라 서비스 식별과 운영의 문제로 다루었다.

라이브러리도 저마다의 가정을 갖고 있었다. 클라이언트는 사용자 지정 서비스 URL을 라이브러리를 위해 HTTP 형태의 URL로 변환해야 할 수 있었고, 그러면 프록시는 절대 URL을 보고 그것을 일반적인 HTTP로 해석할 수 있었다. 재사용된 코드는 애플리케이션이 그 버전 라벨을 어떻게 이해해야 하는지 설명해야 하는 상황에서도HTTP/1.1을 전송할 수 있었다. 라이브러리에 대한 희망적 가정이 아니라 명세가 클라이언트, 서버, 프록시 간의 상호작용을 기술해야 했다.

이는 재사용의 경제성을 바꾼다. 기존 코드는 첫 구현의 비용을 줄일 수 있지만, 그 일반적인 동작이 시스템 경계의 일부가 된다. 독립적인 구현이 많아질수록 한 클라이언트의 지름길이 다른 곳의 캐시 규칙, 프록시 동작 또는 서버 가정과 충돌할 가능성도 커진다. 이것은 이 문서의 설계 분석에서 도출한 추론이지, 공학 비용에 대한 측정된 추정이나 특정 프로토콜이 실패했다는 증거가 아니다.

후속 문서는 그 패턴의 지속을 기록한다

RFC 9205는 2022년, HTTP 개발과 경험이 20년 진행된 뒤 RFC 3205를 대체하여 BCP 56이 되었다. 이는 별개의 구현들에 걸친 HTTP 기반 API, 클라이언트와 서버의 비동기적 진화, 확장성, 캐싱, 상태, 인증, 웹 브라우징과의 공존을 다룬다. 그 존재는 이 설계 문제가 갱신된 지침을 필요로 할 만큼 여전히 관련성이 있었음을 보여준다. 이것은 두 문서 중 어느 쪽의 보편적 채택을 증명하지 않으며, 2002년의 조언이 이후의 모든 API 관행을 예언했다는 뜻도 아니다.

역사적 교훈은 더 좁고 더 유용하다. 프로토콜 재사용은 경계를 지우지 않는다. 경계를 공유 소프트웨어의 의미론 안으로 옮길 뿐이다. 한 구현은 HTTP 라이브러리에 대해 컴파일하면서도, 응답이 무엇을 의미하는지에 대해서는 다른 구현과 불일치할 수 있다. 상호운용성은 주변 HTTP 시스템이 무엇을 할 수 있는지, 애플리케이션이 무엇을 해야 하는지, 각 결과를 어느 계층이 소유하는지를 명확히 밝히는 것을 요구한다.

종단점 사이의 장치들에 대한 현대의 아키텍처 어휘는RFC 3234에서 발전되었다. 원래의 HTTP/1.1 맥락은RFC 2616을, RFC 3205가 사용하지 않기로 한 요구 단어 관례는RFC 2119에 명시되어 있다. 권위 있는 본문, 기록 및 이후의 대체 문서는RFC 3205, 그RFC Editor 기록,IETF Datatracker 기록,RFC 9205와 그RFC Editor 기록이다.