요약

  • 초기 HTTP는 TCP 연결 위에서/를 요청할 수 있었지만, 목적지 주소에는 사용자가 선택한 DNS 이름이 보존되지 않았습니다.
  • HTTP/1.1은Host를 필수로 요구함으로써 서버가 하나의 경로를 올바른 이름 기반 리소스 공간에 배치하고 하나의 IP 주소로 여러 사이트를 호스팅할 수 있게 했습니다.
  • 절대 요청 타깃과 Host 양쪽 모두에 권한(authority)이 나타날 수 있었기 때문에, 사양은 우선순위, 프록시 재작성, 그리고 누락·중복·잘못된 값에 대한 거부 규칙을 정의했습니다.

서버가 받은 것은 주소와 슬래시

RFC 1945는 당시 일반적으로 사용되던 HTTP/1.0의 모습을 기록했습니다. 클라이언트는 이름을 해석해 주소로 TCP 연결을 열고, 대상이 대개 경로만 담은 요청을 보냈습니다. 하나의 주소가 하나의 웹 서버에 대응하던 시절에는GET /만으로도 실무상 충분했습니다. 연결 자체가 유일한 루트를 선택해 주었기 때문입니다.

하지만 이 편의는 확장되지 않았습니다. DNS는 여러 이름을 같은 주소에 매핑할 수 있었지만, 서버는 클라이언트의 DNS 질의를 받지 못했습니다. TCP는 주소와 포트로의 연결만 전달했을 뿐, 사용자가 입력하거나 클릭한 원래의 라벨은 전달하지 않았습니다. 두 사이트가 그 엔드포인트를 공유하는 순간,/는 더 이상 그 경로를 소유한 네임스페이스를 특정하지 못하는 경로가 되었습니다.

HTTP/1.1이 권한을 메시지 안으로 되돌려 넣다

1997년 1월,RFC 2068은Host를 HTTP/1.1 요청의 필수 필드로 만들었습니다. 직접 오리진 요청은 요청 라인에 대개 경로와 쿼리만 담고, Host가 URI의 네트워크 위치를 담았습니다. 정확한 리소스는 이 두 조각이 결합되어 결정되었습니다.

이 규칙은 의도적으로 엄격했습니다. 모든 인터넷 HTTP/1.1 요청은 Host를 포함해야 했고, 서버는 Host가 없을 때 400을 반환해야 했습니다. 부록은 이를 사양에서 가장 중요한 변경 사항 중 하나로 명시했습니다. 그 명시된 목적은 하나의 IP 주소로 여러 웹 사이트를 지원하고, 특수 목적 도메인 이름 구분을 위해서만 소모되던 주소 할당을 되찾는 것이었습니다.

Host는 그 이름을 참으로 만들지 않았습니다. 다만 라우팅에 충분하도록 클라이언트가 의도한 권한을 명시적으로 만들었을 뿐입니다. 오리진은 여전히 그 이름이 서버상에서 유효한지를 스스로 판단해야 했습니다.

하나의 요청이 이름을 두 번 담을 수도 있다

직접 요청은 보통 오리진 형식을 사용합니다. 예를 들어/pub/index같은 경로입니다. 프록시로 보내는 요청은 절대 형식을 사용할 수 있으며, 이 경우 요청 타깃이 이미 스킴, 호스트, 경로를 담고 있습니다. 절대 URI가 한 호스트를 말하는데 Host 필드가 다른 호스트를 말한다면, 양쪽을 무조건 따르는 것은 서로 다른 수신자에게 서로 다른 두 가지 가능한 목적지를 제공합니다.

따라서 RFC 2068은 그 경우 절대 요청 타깃을 권위 있는 것으로 지정했습니다. 이후RFC 7230은 절대 형식을 받은 프록시가 수신한 Host를 무시하고 전달 전에 타깃의 권한으로 교체하도록 요구했습니다. 중개자는 두 개의 표현을 하나의 결정으로 변환합니다.

같은 논리가 강제 거부를 설명합니다. HTTP/1.1 서버는 Host가 없거나, Host 필드가 둘 이상이거나, 값이 잘못된 경우 400으로 응답해야 합니다. 첫 번째, 마지막 또는 가장 편한 사본을 선택하게 되면 프록시, 캐시, 오리진이 요청의 목적지에 대해 서로 불일치하게 됩니다.

완전한 타깃은 읽는 것이 아니라 재구성된다

RFC 7230은 그 결과를 유효 요청 URI(effective request URI)라고 불렀습니다. 요청 형식에 따라 수신자는 서버 구성, 연결 보안 컨텍스트, 요청 타깃, Host를 결합합니다. 경로는 하나의 구성 요소일 뿐이며, 권한이 어떤 리소스 공간이 그것을 해석할지 결정합니다.

이 재구성은 권한을 분산시킵니다. 사용자 에이전트는 자신의 타깃을 선언합니다. 프록시는 전달할 형식을 정규화합니다. 오리진은 그 권한을 자신이 서비스하는지 검증하고 가상 호스트를 선택합니다. 캐시는 라우팅이 사용한 것과 동일한 타깃 아래 응답을 키로 저장해야 합니다. 리다이렉트 생성기는 검증되지 않은 입력으로 외부 이름을 만들어서는 안 됩니다.

RFC 7230은 검증되지 않은 Host 값을 내부 리다이렉션이나 공유 캐시 키로 사용하지 말라고 특별히 경고합니다. 문제는 Host가 선택 사항이거나 장식적이라는 것이 아닙니다. Host는 요청자가 제공하면서도 요청이 어디로 가는지를 바꿀 수 있다는 점이 정확히 문제입니다.

불변 규칙이 되어 살아남은 필드

RFC 9112의 현재 HTTP/1.1 문법은 그 계약을 유지합니다. 타깃 권한이 비어 있는 경우를 포함해, 하나의 유효한 Host 필드가 필수입니다. 이 규칙들은 더 이상 우호적인 휴리스틱이 모호한 요청을 고칠 수 있다고 가정하지 않습니다.

HTTP/2는 표현을 바꿨을 뿐, 그 필요성은 바꾸지 않았습니다.RFC 9113은 타깃 권한을:authority로 전달합니다. 중개자가 HTTP/1.1 요청을 구성할 때는 그 값을 Host로 사용해야 하며, 요청 타깃도 함께 변경하지 않는 한 기존 Host를 교체해야 합니다. 프로토콜 변환은 경쟁하는 여러 권한 주장을 전달하는 것이 아니라 하나의 권한을 보존해야 합니다.

이 역사적 변경은 문법상으로는 작았지만 거버넌스상으로는 컸습니다. 하나의 필수 이름이 하나의 주소-하나의 사이트 가정을 풀어 주었지만, 그 대가로 모든 중개자가 그 이름을 단일하고 일관되게 유지할 책임을 지게 되었습니다.

출처와 한계

닫힌 근거 집합은RFC 1945,RFC 2068,RFC 7230,RFC 9112,RFC 9113입니다. 이는 프로토콜 규칙과 동기를 확립할 뿐, 현재의 가상 호스트 수, 절약된 주소 수, 브라우저 점유율, 제품 기본 설정, 사고 빈도는 다루지 않습니다. Host는 요청 권한을 표현할 뿐, DNS 소유권, TLS 신원 또는 발신자를 인증하지 않습니다.