요약

  • Expect: 100-continue는 클라이언트가 요청 본문을 보내기 전에 잠시 멈출 의사를 드러내게 하여, 서버가 메서드·대상·헤더만으로 거부할 기회를 줍니다.
  • 100 응답은 전송을 장려할 뿐입니다. 원점(origin)은 본문을 처리한 뒤 최종 상태를 여전히 보내야 하며, 중개자가 원점의 수락을 증명하지 않고도 잠정 응답을 생성할 수 있는 경우도 있습니다.
  • 클라이언트는 기다리기를 멈추고 그냥 보낼 수 있습니다. 이 탈출로는 오래되었거나 침묵하는 중개자를 통한 교착을 방지하므로, 이 메커니즘은 트랜잭션 프로토콜이 아니라 최적화입니다.

결정 가능한 부분 다음에 비용이 컸다

HTTP는 선택적 본문 앞에 요청 라인과 헤더 섹션을 먼저 보냅니다. 이 순서는 기회를 만듭니다. 서버는 메서드, 대상 URI, 인증 필드, 콘텐츠 메타데이터만으로 요청이 실패할 것임을 이미 알 수 있고, 그동안 클라이언트는 큰 본문을 아직 손에 들고 있습니다.

초기 판정이 401, 405 또는 다른 최종 거부라면 모든 것을 즉시 보내는 것은 용량을 낭비합니다. 반대로 공유된 신호 없이 기다리면 위험은 반대 방향으로 생깁니다. 클라이언트는 허가를 기다리고, 서버는 본문을 기다립니다.100 Continue는 바로 그 간격 속에서 설계되었습니다.

RFC 2068, 즉 1997년의 첫 HTTP/1.1 표준 트랙 사양은 이 정보성 상태와 광범위한 버전 민감 동작을 정의했습니다. HTTP/1.1 서버는 본문을 초대하거나 도착 전에 거부할 수 있음을 인식했습니다. HTTP/1.0과의 호환성 때문에 교환이 까다로웠는데, 오래된 홉(hop)이 잠정 응답을 전달하리라 신뢰할 수 없었기 때문입니다.

기대(expectation)가 대기 상태를 가시화했다

RFC 2616은Expect필드와100-continue기대값을 추가했습니다. 클라이언트는 더 이상 프로토콜 버전과 타이밍에만 의존하지 않습니다. 기다릴 의사가 있는 클라이언트는 요청 헤더에 그 선택을 선언했습니다.

이 구분이 중요한 이유는 많은 클라이언트가 멈추지 않고 헤더와 본문을 함께 보내기 때문입니다. 본문의 일부 또는 전부를 이미 받은 서버는 이제 무의미한 100을 보낼 필요가 없습니다. 반대로 클라이언트는 본문이 없는 요청에 이 기대값을 표시해서는 안 됩니다. 이 신호는 구체적이고 예정된 지출을 설명합니다.

나중에 통합된 규칙에서, 조건에 맞는 HTTP/1.1 요청을 받은 원점은 완전한 헤더 섹션으로부터 판단해야 합니다. 그 필드들이 이미 최종 상태를 정당화한다면 즉시 그 상태를 보낼 수 있습니다. 그렇지 않다면 100을 신속히 보내야 하며, 본문을 기다렸다가 보내서는 안 됩니다.

이 타이밍 규칙은 잠정적 교환이 막으려던 바로 그 교착을 일으키지 않게 합니다. 원점은 헤더 기반 판정을 주거나, 전송자가 계속하도록 놓아줍니다.

Continue는 수락을 의미하지 않았다

1xx 응답은 정보성입니다. 응답 본문이 없고, 요청을 완료하지도 않습니다. 서버가 100을 보냈다면, 연결이 조기에 끊어지는 경우를 제외하고 콘텐츠를 받아 처리한 뒤 최종 상태를 만들어야 합니다.

경계는 승인이나 준비 같은 익숙한 단어들이 암시하는 것보다 좁습니다. 서버는 주체(principal)를 인증하거나, 표현을 수락하거나, 바이트를 영구 저장하거나, 메서드를 수행하거나, 성공을 반환하겠다고 약속한 것이 아닙니다. 지금까지 본 정보가 콘텐츠 전송을 멈출 충분한 이유가 아니라는 것만 말한 것입니다.

그래서 이것은 2단계 커밋이 아닙니다. 본문은 여전히 검증에 실패할 수 있고, 저장은 실패할 수 있고, 애플리케이션 상태는 바뀔 수 있으며, 인가는 콘텐츠에 의존할 수 있습니다. 잠정적 허가는 전송을 통제할 뿐, 연산의 최종 의미를 통제하지 않습니다.

프록시는 자신이 수락할 수 없는 일을 장려할 수 있었다

HTTP 중개자는 허가의 출처를 복잡하게 만듭니다. 기대값을 받은 프록시는 자신이 판정할 수 있는 최종 응답을 보내거나, 요청 라인과 헤더를 원점 쪽으로 전달할 수 있습니다. 다음 홉이 오래되었다는 것을 알면, 클라이언트를 계속 움직이게 하기 위해 스스로 100을 생성할 수도 있습니다.

이런 응답은 즉시 인접 체계가 콘텐츠 전달을 계속할 의사가 있음만 증명합니다. 원점이 요청을 보았다는 것, 더군다나 수락했다는 것을 보여주지 않습니다. 어느 홉이 보냈는지 밝히지 않은 채 "100 수신"만 기록하는 운영 로그는 통제 경계를 지워버립니다.

417 Expectation Failed 응답은 다른 사실을 드러냅니다. 그 기대값이 체계를 따라 충족될 수 없었다는 것입니다. 사양은 기대값 없이 재시도하라고 조언합니다. 그 조언은 선택적 최적화를 제거할 뿐, 모든 재시도가 무해하다는 뜻이 아닙니다. 상태 변경 메서드는 여전히 무엇이 원점에 도달했는지, 반복이 안전한지에 대한 증거를 필요로 합니다.

진행이 허가를 듣는 데 의존할 수는 없었다

RFC 7231과RFC 9110은 본질적인 비대칭을 유지합니다. 클라이언트는 특정 시간을 기다릴 의무가 없고, 100을 받지 못하더라도 콘텐츠 전송을 시작할 수 있습니다. 무한히 기다려서는 안 됩니다.

오래된 중개자는 1xx를 삼킬 수 있습니다. 서버는 이미 본문을 받고 있을 수 있습니다. 침묵하는 경로가 양쪽을 영원히 붙잡고 있게 해서는 안 됩니다. 그래서 클라이언트가 주도하는 타임아웃은 일부 낭비될 수 있는 바이트를 보장된 진행과 맞바꿉니다.

이는 또한 서버가 침묵을 통해 무기한 거부권을 갖는 일을 막습니다. 클라이언트는 조기 의견을 요청하지만, 기다림이 충분한 비용이 되었는지는 스스로 판단합니다. 이 최적화는 본문이 크거나 조기 거부 가능성이 클 때 가장 유용하며, 표준은 의도적으로 하나의 보편적 임계값을 정하지 않습니다.

조기 최종 응답은 프레이밍 문제를 남긴다

최종 응답은 클라이언트가 아직 전송 중인 동안 도착할 수 있습니다. 이때 연결에는 두 가지 문제가 공존합니다. 애플리케이션 판정과 남은 요청 바이트입니다. 서버는 연결을 닫을 수도 있고, 나중 메시지의 프레이밍이 유지되도록 콘텐츠를 계속 읽어 버릴 수도 있습니다.

연결 재사용은 이것을 단순한 정리 이상으로 만듭니다. 전송자와 수신자가 본문이 아직 스트림 위에 있는지에 대해 의견이 갈리면, 남은 바이트가 다른 메시지로 오인될 수 있습니다. 따라서 허가, 최종 결과, 연결 처분은 각각 따로 관찰되어야 합니다.

출처와 한계

닫힌 근거 집합은RFC 2068,RFC 2616,RFC 7231,RFC 9110입니다. 이는 프로토콜의 진화와 의미론을 확립할 뿐, 현재의 채택 현황, 타임아웃 기본값, 중개자 준수 수준, 절약된 대역폭 또는 성능에 대해서는 다루지 않습니다.