Summary

  • RFC 6265는 왕복 경로를 설명한다. 서버가 Set-Cookie로 이름과 값을 보내면 브라우저는 조건에 맞는 다음 요청에 이를 Cookie로 돌려준다. 규격은 서버에 쿠키를 적고 작게 쓰라고 권한다.
  • RFC 6585는 2012년 4월 헤더 전체 또는 한 필드가 너무 클 때 쓰는 431을 도입했다. 줄인 요청은 다시 보낼 수 있고 431 응답은 캐시에 보관할 수 없다.
  • HTTP/2와 HTTP/3에서도 서버는 처리하기에 지나치게 큰 필드 묶음이나 헤더 구역을 431로 거절할 수 있다.

보내는 쪽이 싼 짐이 되돌아왔다

손님이 온라인 상점에 다시 들어온다. 브라우저는 첫 화면을 요청하며 Cookie를 붙인다. 로그인 세션, 취향 설정, 실험용 값들이 담겨 있다. 앞선 방문에서 그 값들을 저장하라고 한 쪽은 상점이었다. 그런데 게이트웨이나 서버가 들어오는 헤더를 재고는 허용 크기를 넘었다고 판단한다. 손님에게 돌아오는 것은 화면 대신 431이다. 상점이 짐을 싸서 쥐여주고는 그 짐을 든 손님을 문전박대한다.

이 흐름은 2011년 4월 나온 RFC 6265에 적혀 있다. 서버는 Set-Cookie로 이름과 값을 보내고, 브라우저는 도메인과 경로 등의 조건을 확인한 뒤 해당하는 후속 요청에 그 쌍을 Cookie로 실어 보낸다. 유효기간과 적용 범위를 정하는 속성 자체가 이름-값 쌍으로 되돌아오는 것은 아니다. 하지만 이름과 값은 조건에 맞는 요청마다 반복해서 돌아온다. 한 번의 서버 지시가 매번의 운반 비용이 된다.

6.1절의 숫자는 서로 다른 한도를 구분하게 만든다. 범용 브라우저는 쿠키 하나에 적어도 4096바이트, 도메인 하나에 적어도 50개의 쿠키를 저장할 수 있어야 한다. 바로 같은 절에서 규격은 서버가 쿠키를 적고 작게 만들라고 말한다. Cookie가 해당하는 모든 요청에 따라오기 때문이다. 4096바이트는 브라우저 저장 능력의 최소치다. 모든 게이트웨이와 애플리케이션이 쿠키가 쌓인 요청 헤더 전체를 받아들이겠다는 약속이 아니다. 한쪽이 기억할 수 있는 양이 다른 쪽의 접수 창구보다 클 수 있다.

431은 막힘을 설명한다

2012년 4월 RFC 6585는 HTTP 상태 코드 네 개를 더했다. 431 Request Header Fields Too Large는 필드의 합계가 너무 클 때도, 필드 하나가 너무 클 때도 쓸 수 있다. 한 필드가 문제라면 응답 본문에서 그 필드를 짚어야 한다. 필드를 줄인 요청은 다시 시도할 수 있다. 431 응답을 캐시에 저장하는 것은 금지된다. 지금의 큰 요청에 대한 거절을 나중의 다른 요청에도 재사용하지 못하게 하는 규칙이다.

하지만 코드에는 인터넷 전체에 적용되는 바이트 상한도, 어느 쿠키를 지우라는 명령도 없다. 공격을 받는 서버는 431을 만드는 대신 연결을 끊을 수도 있다. 이용자는 단순히 페이지가 열리지 않는다고 느낀다. 애플리케이션이 요청을 보기 전 게이트웨이가 거절했을 가능성도 있다. 어느 지점에서 문이 닫혔는지는 그 지점의 요청 기록을 봐야 알 수 있다.

모든 쿠키를 지우면 요청이 가벼워질 수 있다. 동시에 로그인과 설정도 사라질 수 있다. 사이트가 다시 같은 값들을 설정하면 문제는 되돌아온다. 도움말 페이지에 가는 요청도 똑같이 큰 헤더를 요구한다면, 도움말마저 잠긴 문 뒤에 놓인다. 값을 발행한 서비스는 어떤 쿠키를 얼마 동안 어느 경로에 보내도록 했는지 알 수 있다. 짐의 원천을 줄일 수 있는 주체도 그 서비스다.

전송을 압축해도 문은 넓어지지 않는다

2022년의 RFC 9113는 HTTP/2 서버가 감당하고 싶지 않은 큰 필드 블록에 431로 답할 수 있다고 적는다. RFC 9114는 HTTP/3의 헤더 구역에도 같은 선택을 남긴다. 압축은 전송 중의 표현을 줄인다. 받는 쪽이 해석해야 할 필드의 양과 그쪽에서 정한 처리 예산은 그대로 문제로 남는다.

장애 회의에서 서로 맞는 두 그래프가 다툴 수 있다. 네트워크는 전송량이 작다고 말하고, 입구는 풀어 놓은 헤더가 너무 크다고 말한다. 커다란 Cookie 하나인지, 평범한 필드가 여러 개 쌓인 것인지도 갈라 봐야 한다. 인증 정보 같은 다른 필드도 같은 공간을 쓴다. 네 RFC에는 쿠키 때문에 일어난 실제 431 사고 건수가 없다. 특정 사건을 판정하려면 처음 거절한 구성요소의 요청 캡처와 기록이 필요하다.

이 역사의 핵심은 작업의 분리다. 브라우저는 맡은 상태를 돌려주고, 인프라는 입구의 한도를 지키며, 애플리케이션은 요청을 보지도 못할 수 있다. 손님에게는 하나의 사이트만 보인다. 431은 반송장에 이유를 적게 해준다. 그 반송을 멈추려면 발행하는 상태와 받아들이는 한도를 같은 조직이 함께 다뤄야 한다.