연결이 곧 권위가 아니었던 이유: HTTP에 421이 필요했던 순간

요약

• HTTP/2는 DNS와 인증서 근거가 재사용을 뒷받침할 때 하나의 지속적 멀티플렉스 연결이 여러 URI 권위(authority)에 대한 요청을 전달할 자격을 갖도록 했다. 그러나 그 자격이 곧, 첫 핸드셰이크에서 선택된 연결 컨텍스트 뒤에 커버된 모든 오리진이 구성되어 있다는 증명은 아니었다.
• 421 Misdirected Request는 오리진 서버, 혹은 오리진을 대리하는 게이트웨이가 URI가 옮겨갔거나 요청이 형식적으로 잘못됐거나 인증서가 반드시 실패했다고 주장하지 않고도 해당 오리진–연결 페어링을 거부할 수 있게 해 준다. 클라이언트는 메서드가 멱등하지 않더라도 다른 연결을 통해 동일한 작업을 재시도할 수 있다.
• RFC 8336은 이후 HTTP/2 서버가 실패한 요청 이전에 Origin Set을 광고할 수 있게 하고, 이를 구현한 클라이언트에게 421 이후 해당 오리진을 그 연결의 집합에서 제거할 것을 요구했다. HTTP/3는 QUIC 위에서도 이 상태 코드를 유지했다. 이는 지속적인 쟁점이 TCP의 특성이 아니라 연결 공유 하의 권위 문제임을 보여준다.

하나의 좋은 연결이 두 번째 이름을 끌어들였다

클라이언트가 이미 한 웹사이트를 위해 암호화된 연결을 열어 두었다고 하자. 엔드포인트는 살아 있고, 핸드셰이크는 성공했으며, 서버는 그 신원 목록이 두 번째 웹사이트까지 커버하는 인증서를 제시했다. 이름 확인 결과는 두 번째 사이트도 같은 엔드포인트에 도달할 수 있다고 클라이언트에게 믿을 이유를 준다.

새 연결을 여는 것은 같은 작업을 반복하는 일이다. 첫 연결을 재사용하면 설정 지연을 피하고 전송 계층 상태를 아낄 수 있고, 두 번째 요청이 이미 유용한 일을 하고 있는 채널을 함께 쓸 수 있다. HTTP/2는 바로 이런 동시성이 가치를 갖도록 설계되었다. 여러 요청 스트림이 새 연결을 차례로 기다리는 대신 하나의 지속적 연결 위를 독립적으로 오갈 수 있었다.

재사용 결정은 거의 자명해 보인다. 채널은 올바른 장비에 닿아 있고, 자격 증명은 올바른 이름을 인식한다. 왜 두 번째 요청을 보내지 않는가?

첫 핸드셰이크가 선택한 것은 암호화만이 아니었을 수 있기 때문이다. 그 Server Name Indication은 가상 서비스, TLS 종단 정책, 고객 파티션, 오리진 백엔드 중 하나를 골랐을 수 있다. 인증서는 여러 이름을 기술할 수 있지만, 이 연결을 위해 선택된 실제 내부 경로는 그중 하나만을 서비스할 수 있다. 네트워크 근거가 클라이언트의 시도를 정당화할 수는 있어도, 수신 배치가 그것을 받아들여야 할 의무까지 만들지는 않는다.

HTTP는 바로 이 정확한 불일치에 대한 응답이 필요했다. 그 결과가 421이었다.

Host는 대상을 지칭했을 뿐, 모든 경로를 결정하지 않았다

HTTP의 이전 역사는 이미 연결 주소와 이름 붙은 자원 공간을 분리해 왔다. 수많은 웹사이트가 하나의 IP 주소를 공유하게 되면서, 오리진이 TCP 목적지만으로 의도된 사이트를 추론할 수는 없었다. HTTP/1.1은Host필드를 의무화하여 각 요청이 대상의 호스트와 포트를 실어 나르게 했다. HTTP/2와 HTTP/3는 보통 같은 권위 정보를:authority로 실어 나른다.

이것은 식별 문제를 해결했다. 즉, 이 요청이 어느 오리진을 의미하는가? 그러나 서버의 라우팅 문제를 없애지는 않았다. 이 오리진이 여기에 구성되어 있는가, 그리고 이 특정 연결의 컨텍스트가 그 오리진에 적합한가?

현재의HTTP 의미론은 양쪽을 모두 보존한다. 요청 대상의 호스트와 포트는 서버가 제어할 수 있는 다른 오리진 네임스페이스와 하나를 구분해 준다. 그러나 요청을 충분히 수신해 대상 URI를 식별한 뒤에도, 서버는 그 요청을 자체적으로 처리할지, 전달할지, 리다이렉트할지, 거부할지, 연결을 닫을지를 여전히 스스로 결정한다. 파싱된 authority 문자열이 모든 내부 경로를 유효하게 만든다고 가정하는 대신, 스킴별 요구 사항과 연결 컨텍스트를 확인해야 한다.

따라서 Host는 클라이언트의 의도를 표현할 뿐이다. 소켓을 통해 닿을 수 있는 모든 프로세스가 그 이름을 대변하라는 명령을 내리지는 않는다.

HTTP/2가 추론을 시도할 만한 가치를 갖게 했다

최초의HTTP/2 명세인 RFC 7540은 2015년 5월에 발표되었다. 이 문서는 지속적 연결을 권장했고, 서버가 해당 오리진에 대한 권위로 보이는 경우 오리진 서버로의 연결을 서로 다른 URI authority 구성 요소를 지닌 요청에 재사용할 수 있도록 허용했다.

암호화되지 않은 TCP 연결의 경우 이 규칙은 추가 호스트가 같은 IP 주소로 확인되는 데 의존했다. HTTPS의 경우 인증서가 클라이언트가 새 연결을 열 때 수행했을 검사 기준에서 새 호스트에 대해서도 유효해야 했다. 하나의 인증서는 여러 subject alternative name이나 적용 가능한 와일드카드를 통해 여러 오리진에 대한 권위 근거를 성립시킬 수 있었다.

이 조건들은 실용적인 클라이언트 측 검사였다. 재사용이 '어떤 엔드포인트든 어떤 이름이든 대답할 수 있다'는 막연한 가정으로 흐르지 않게 막았다. 그러나 그 조건들은 엔드포인트 뒤의 배치 전체를 볼 수 없었다.

RFC 7540은 구체적인 실패 양상을 제시했다. 미들박스가 TLS를 종단하고 연결 수립 시 제공된 SNI 값을 사용해 오리진 서버를 선택할 수 있다. 그러면 이후 다른 인증서 커버 오리진에 대한 요청이 기존 연결을 타고, 의도된 대상이 아닌 서버 컨텍스트로 흘러들 수 있다. 인증서가 반드시 위조였던 것도, DNS가 반드시 오염되었던 것도, 요청이 반드시 형식적으로 잘못되었던 것도 아니다. 클라이언트는 불완전한 근거로부터 합리적인 추론을 했을 뿐이다.

빠져 있는 사실을 쥐고 있는 쪽은 수신 측이었다. 즉, 이 요청은 이 연결에 속하지 않는다.

421은 존재를 부정한 것이 아니라 페어링을 거부한 것이다

RFC 7540은 그 사례를 위해421 Misdirected Request를 도입했다. 현재의 정의는 HTTP/2 문서가 아니라 RFC 9110에 자리하고 있다. 이 정의에 따르면 서버는 대상 URI에 대한 권위 있는 응답을 내놓을 수 없거나 내놓으려 하지 않는다. 대상이 그곳에 구성된 어떤 오리진과도 일치하지 않을 수 있고, 혹은 요청이 도달한 컨텍스트와 일치하지 않을 수 있다.

범위가 중요하다. 이 응답은 자원이 사라졌다고 말하지 않는다. 오리진이 이동했다고 말하지 않는다. 클라이언트에게 새 URI를 만들라고 요구하지도 않는다. 이 연결에 구현된 경로가 그 대상에 대해 권위 있게 대답하기를 거절하는 컨텍스트에 닿았다고 말할 뿐이다.

오리진 서버가 이 판단을 내릴 수 있다. 오리진을 대리하는 게이트웨이도 가능하다. 그런 게이트웨이는 오리진의 서빙 경계에 참여하기 때문이다. 일반 프록시는 불가능하다. RFC 9110은 프록시가 421을 생성해서는 안 된다고 명시한다.

이 금지는 부정적 근거가 그것이 기술하는 구성을 지닌 권위에 귀속되도록 유지한다. 임의의 전달 홉이 이 응답을 만들어 낼 수 있다면, 클라이언트는 오리진이 연결 컨텍스트를 거부한 것인지, 아니면 중개자가 다른 경로를 선호했을 뿐인지 알 수 없게 된다.

유효한 인증서는 필요 근거였지, 보편적 면허가 아니었다

현대 인프라는 종종 인증서를 운영 장비를 공유할 수 있는 이름들의 목록처럼 다룬다. 유용하지만 과잉 해석하기 쉽다.

인증서는 피어가 클라이언트의 검증 규칙에서 수용하는 신원과 연관된 개인 키를 통제한다는 것을 증명한다. 그러나 그 신원 목록의 모든 이름이, 그 인증서로 세워지는 모든 연결에서 같은 테넌트, 포트 정책, 애플리케이션, 백엔드 풀, 보안 경계에 들어간다는 것을 증명하지는 않는다. 인증서의 폭과 서빙 구성은 겹칠 수 있지만 동일하지 않다.

세 가지 명제를 분리해 두면 구분이 선명해진다.

첫째, 도달 가능성: 이 채널은 어떤 엔드포인트에 닿는다. 둘째, 자격 증명 커버리지: 엔드포인트가 대상 오리진에 대해 수용 가능한 근거로 인증했다. 셋째, 연결 컨텍스트 수용: 수신 배치가 구성되어 있고, 이 특정 채널 위에서 그 오리진의 권위 있는 응답을 내놓을 의사가 있다.

앞의 두 명제는 재사용이 추측 이상이 되도록 충분히 강하다. 그러나 세 번째 결정을 서버로부터 빼앗을 만큼은 강하지 않다. 421은 그 마지막 명제에 대한 서버의 유한한 거부권이다.

이것은 최적화에 대한 적대가 아니다. 낙관적 최적화를 통제 가능하게 만드는 것이 바로 이것이다. 클라이언트는 자신이 가진 근거에 따라 행동하되, 자신의 추론이 되돌릴 수 없는 것처럼 행세하지 않는다.

재시도는 요청을 보존하고 컨텍스트를 바꿨다

복구 규칙은 이례적으로 명시적이다. 421을 받은 클라이언트는 다른 연결을 통해 요청을 재시도할 수 있다. 대상 오리진 전용의 새 연결이든, 적절한 대안 서비스로의 연결이든 가능하며, 이 허용은 메서드가 멱등한지와 무관하게 적용된다.

이 마지막 조항을 일반화해서는 안 된다. HTTP는 모든 실패한 비멱등 요청을 안전하게 재생할 수 있다고 선언하지 않는다. 응답 서버가 이 컨텍스트에서 대상 오리진의 권위 있는 응답을 내놓기를 거절한, 유형화된 거부를 기술하고 있을 뿐이다. 이 상태 코드는 클라이언트가 다른 연결을 미지의 애플리케이션 결과 이후의 반복이 아니라 라우팅 컨텍스트의 수정으로 다룰 근거를 준다.

그렇다 해도MAY는 클라이언트에게 재량을 남긴다. 로컬 정책이 재생을 거부할 수 있고, 자격 증명이 연결에 결합되어 있을 수 있으며, 요청 본문이 재현 불가능할 수 있고, 애플리케이션이 결과에 중요한 작업의 반복 전에 확인을 요구할 수 있다. 프로토콜은 복구를 허용할 뿐, 위험을 강요하지 않는다.

개념적으로 요구되는 것은 변화된 조건이다. 새 근거도 한도도 없이 같은 병합된 연결 위에 같은 요청을 다시 보내는 일은 복구 메커니즘을 루프로 만든다. 대상 URI는 안정적으로 유지되고, 바뀌는 것은 연결 선택이다.

새 연결은 결국 같은 주소에 닿고 같은 인증서를 제시하더라도 의미를 가질 수 있다. 그 핸드셰이크는 대상 오리진의 SNI를 실어 다른 서비스 컨텍스트를 선택하고 더 좁은 운영 경로를 성립시킬 수 있다.

421은 위장된 리다이렉트가 아니었다

리다이렉트는 클라이언트에게 다른 대상을 고려하라고 요청한다. 보통 다음 요청의 목적지나 식별을 바꾸는 URI를 담은 location을 실는다. 421 응답은 어느 쪽도 하지 않는다.

클라이언트에게 콘텐츠가 다른 곳에 있다고 말하지 않는다. 이미 이름 지어진 URI를 이 서버 컨텍스트가 권위 있게 대답할 수 없거나 하지 않겠다고 말할 뿐이다. 복구는 같은 의미를 다른 연결을 통해 전달하려는 시도다.

이 구분이 책임성을 지킨다. 운영자가 라우팅 불일치에 리다이렉트로 응답하면 내부 호스트명이 노출되거나, 자격 증명이 다른 권위로 이전되거나, 캐시 키가 바뀌거나, 원래 배치의 오리진 맵이 일관되지 않다는 사실이 감춰질 수 있다. 클라이언트가 421을 URI를 바꿀 허가로 해석하면, 그런 주장을 한 적 없는 응답에게 의미적 선택을 위임하게 된다.

421은400 Bad Request와도 동치가 아니다. 요청은 문법적으로 올바를 수 있다.403 Forbidden과도 다르다. 핵심 사실은 사용자의 자원 접근 권한 부족이 아니기 때문이다. TLS 경고도 아니다. TLS는 설계대로 정확히 성공했을 수 있다.

좁은 상태 코드의 가치는 한 계층의 오류 어휘가 다른 계층의 의미에 대한 권위를 취득하는 일을 막는 데 있다.

ORIGIN은 실수가 일어나기 전에 대화의 일부를 앞당겼다

반응적 수정에는 시간이 든다. 클라이언트가 요청을 보내고 421을 받고 다른 연결을 열거나 선택해 다시 시도한다. 2018년 3월에 발표된RFC 8336은 HTTP/2ORIGIN프레임을 도입하여, 서버가 어떤 오리진을 위해 이 연결을 쓸 수 있는지에 대한 사전 정보를 클라이언트에 줄 수 있게 했다.

이 확장은 연결에 대한 Origin Set을 정의한다. 그 집합이 한 번 초기화되면, 이를 지원하는 클라이언트는 집합에 없는 오리진에 대해 그 연결을 권위 있는 것으로 간주해서는 안 된다. 항목은 명시적 오리진이며 와일드카드 이름은 허용되지 않는다. 따라서 와일드카드 인증서가 자동으로 무제한의 ORIGIN 광고가 되지는 않는다.

이 신호는 하나의 연결을 기술하기 때문에 홉 단위다. 중개자는 이를 전달하지 않고, 프록시를 사용하도록 구성된 클라이언트는 그 프록시로부터 이 신호를 무시한다. 서버는 이후 프레임을 통해 오리진을 점진적으로 추가할 수 있지만, 인증서 검증은 여전히 필요하다. ORIGIN은 대체 자격 증명이 아니며, 서버가 이름을 나열했다는 이유만으로 그 이름을 부여하지 않는다.

RFC 8336은 피드백 루프도 닫는다. 이를 지원하는 클라이언트가 421을 받으면 해당 오리진을 그 연결의 Origin Set에서 제거한다. 부정적 응답은 더 이상 고립된 오류 페이지가 아니라, 그 오리진에 대한 이후 요청이 가서는 안 되는 곳에 대한 클라이언트의 모델을 갱신한다.

가장 정밀한 기억 키는 오리진에 연결을 더한 것이다. 오리진을 전역적으로 제거하면 국소적 불일치에서 과잉 학습하게 되고, 응답을 즉시 잊으면 같은 실패한 추론을 반복하게 된다.

Alt-Svc는 엔드포인트를 지명하되 권위 검사를 지우지 않았다

오리진은 대안 서비스를 광고할 수 있어, 클라이언트가 같은 오리진을 위해 다른 호스트, 포트 또는 프로토콜 엔드포인트를 사용할 수 있다. 이는 또 하나의 경로 선택 기회를 만들지만, 광고 자체가 권위 모델을 다시 쓰지는 않는다.

RFC 8336은 Alt-Svc 광고가 Origin Set을 수정하지 않는다고 명시한다. RFC 9110의 421 복구가 대안 서비스를 선택할 수 있지만, 선택된 연결에는 여전히 대상 오리진에 적합한 근거와 구성이 필요하다.

이는 편리한 신호들의 사슬이 순환 증명이 되는 것을 막는다. 인증서는 인증을 뒷받침할 수 있다. DNS는 도달 가능성을 뒷받침할 수 있다. Alt-Svc는 대안을 지명할 수 있다. ORIGIN은 연결의 의도된 오리진 집합을 진술할 수 있다. 그중 어느 하나만으로 다른 모든 명제가 증명되지는 않으며, 수신 컨텍스트가 그 조합을 거부하면 421은 여전히 사용 가능하다.

얇은 신호들이 협력하는 이유는 그 주장들이 유한하기 때문이다.

HTTP/3는 전송을 바꾸되 거부권을 유지했다

현재의HTTP/2 명세인 RFC 9113은 RFC 7540을 대체하면서 교차 오리진 연결 재사용과 421을 유지한다.HTTP/3인 RFC 9114는 같은 경계를 QUIC으로 가져간다.

HTTP/3는 더 이상 TCP 위에서 동작하지 않지만, 그 연결은 여전히 지속적이며 서로 다른 URI authority에 대해 재사용될 수 있다. 기존 연결을 새 오리진에 사용하기 전에 클라이언트는 그 오리진에 대한 인증서를 검증해야 한다. 인증서가 수용 불가하면 재사용은 금지된다. 수용 가능한 검증 후에도, 특정 오리진에 대해 HTTP/3 연결의 재사용을 원치 않는 서버는 421을 반환할 수 있다.

이 생존은 의미심장하다. 이 상태 코드는 HTTP/2에서 태어났지만, 그 의미는 이후 일반 HTTP 의미론으로 옮겨져 HTTP/3에서도 쓰인다. 근본 문제는 특정 이진 프레임이나 TCP의 연결 장치가 아니다. 성능이 여러 개의 이름 지어진 권위가 하나의 채널을 공유하도록 허용하는 한, 수신 배치가 송신자가 완전히 볼 수 없는 컨텍스트를 보유하는 곳마다 나타난다.

효율이 추론을 만들었다. 분산된 권위는 그 추론에서 벗어날 출구를 필요로 했다.

올바른 관찰 가능성은 실패한 에지를 따른다

연결 컨텍스트 없는 421 카운터는 거의 아무것도 말해 주지 않는다. 운영자는 어떤 대상 오리진이 어떤 채널을 타고 전달되었는지, 그 채널이 왜 선택되었는지, 재시도에서 무엇이 바뀌었는지 알아야 한다.

유용한 근거로는 스킴, 호스트, 포트; 요청 메서드; 연결 식별자; 협상된 HTTP 버전; 원격 엔드포인트; SNI; ALPN; 인증서 신원 집합; 재사용에 쓰인 DNS 근거; Alt-Svc 출처; 광고된 Origin Set; 선택된 프론트엔드와 백엔드; 421을 발생시킨 주체의 역할; 그리고 재시도 연결의 식별자(있다면)가 있다.

경로 간 비교가 특히 가치 있다. 오리진 전용의 새 연결이 성공하는 동안 병합된 연결이 421을 반환한다면, 연결 컨텍스트 선택이 최유력 설명이 된다. 둘 다 421을 반환한다면 오리진이 아예 없거나 더 넓게 잘못 구성되었을 수 있다. 배치 지역 하나에서만 실패한다면 공유된 인증서나 광고가 백엔드 수렴을 앞서 갔을 수 있다.

이 상태는 조사할 만큼 드물면서도 당황할 만큼 낯설지 않아야 한다. 낙관적 시도에 대한 건강한 수정일 수 있다. 경고는 수렴 없는 반복이다.

부정적 응답은 다원적 통제를 보호했다

연결 병합은 집중이 효율적이기 때문에 작업을 집중시킨다. 핸드셰이크를 줄이고, 하나의 스케줄러와 혼잡 컨텍스트가 여러 스트림을 나를 수 있게 한다. 그 이득은 첫 연결이 그 인증서가 이름 지을 수 있는 모든 오리진에 대한 주권을 갖도록 요구되지 않는다.

재사용 결정은 클라이언트가 통제한다. 인증서 기관과 검증 정책은 수용 가능한 신원 근거를 형성한다. DNS와 대안 서비스 레코드는 엔드포인트 선택을 형성한다. TLS 종단기는 서비스 컨텍스트를 선택할 수 있다. 오리진 운영자는 권위와 연결 컨텍스트에서 응답할 준비된 애플리케이션으로의 맵을 통제한다. 각 계층은 근거를 제공하되 보편적 위임장을 받지 않는다.

421은 그 분배를 보존할 만큼 작다. 백엔드를 설계하지 않고, 새 오리진을 임명하지 않으며, 빠진 구성 사실을 쥔 쪽에게 요청의 신원을 온전히 남긴 채 시도된 하나의 에지를 정밀하게 거부할 방법을 준다.

인터넷은 흔히 추론을 제거함으로써가 아니라, 더 나은 근거가 존재하는 경계에서 추론을 되돌릴 수 있게 함으로써 더 안전해진다.

연결은 실재했지만, 그 위임은 아니었다

유혹적인 실수는 성공적인 수립을 완전한 권위와 동등하게 여기는 것이다. 소켓이 존재하므로 인증서의 모든 이름이 그 위에 속해야 한다. 멀티플렉스 채널이 효율적이므로 도달할 수 있는 모든 서비스가 그 상속된 컨텍스트를 수용해야 한다. 클라이언트가 보이는 모든 사전조건을 확인했으므로 서버가 그 결과를 존중해야 한다.

HTTP 421은 그 확대를 거부한다.

연결은 여전히 실재한다. 적절한 오리진을 계속 서비스할 수 있다. 두 번째 오리진도 실재한다. 새 연결이 그것에 성공적으로 닿을 수 있다. 실패한 것은 그 순간 그 오리진을 그 연결에 결합하려던 명제였다.

현재IANA HTTP 상태 코드 레지스트리는 421을 Misdirected Request로 기록하고 RFC 9110을 가리킨다. 등록은 상호운용 가능한 이름과 참조를 확정할 뿐이다. 그것이 이 상태가 얼마나 자주 나타나는지, 모든 클라이언트가 재시도하는지, 어떤 특정 배치가 오리진 경계를 올바르게 구성했는지를 증명하지는 않는다.

HTTP는 어느 한쪽 엔드포인트를 비난하는 대신 실패한 에지를 이름 지음으로써, 성능을 권위에 종속시켰다. 하나의 채널이 많은 스트림을 나르되, 공유된 전송이 공유된 규칙이 되지는 않았다.