요약

  • HTTP/1.0은 이미 204를, 표시할 새로운 정보가 없는 처리 완료된 요청에 사용했습니다. 사용자 에이전트는 해당 요청을 유발한 문서 화면을 유지하도록 되어 있었고, 이동하거나 지우지 않았습니다.
  • “No Content”는 “상태 없음”이나 “메타데이터 없음”을 뜻하지 않습니다. 현재 시맨틱스에 따르면 응답 헤더는 동작 이후 대상 리소스와 선택된 표현을 기술하며, PUT 이후 ETag는 새로 저장된 표현을 식별할 수 있습니다.
  • 204는 헤더 섹션에서 끝납니다. 본문이나 트레일러를 포함할 수 없고, 현재 HTTP는Content-Length를 금지합니다. 빈 응답의 경계는 프로토콜 의미이며, 선택적 서식 기호가 아닙니다.

성공이 항상 새 페이지를 필요로 하지는 않았다

초기 웹 상호작용은 종종 두 사건을 하나로 묶었습니다. 동작이 완료되고, 그다음 새 문서가 나타났습니다. 검색 결과나, 결과 자체가 표현을 가질 만한 가치가 있는 제출에는 합리적이었습니다. 그러나 무언가를 변경하고, 그 변경을 확인하며 사용자가 이미 있던 곳에서 계속 작업하도록 하는 또 다른 흔한 패턴에는 낭비였습니다.

문서를 저장하는 편집기를 생각해 보십시오. 저장이 일어났음을 증명하기 위해 원 서버가 문서를 다시 보내줄 필요는 없습니다. 성공이 편집기를 작업 화면에서 떠나게 강제해서도 안 됩니다. 유용한 결과는 더 작습니다. 동작이 완료되었다, 지금부터 이것이 리소스의 버전 식별자이다, 계속하라.

HTTP 204는 그 결과를 명시적으로 만들었습니다. 빈 200을 쓰고 인터페이스 시맨틱스를 추측에 맡기지 않았습니다. 응답 본문의 부재가 계약의 일부인 상태 코드를 배정했습니다.

바로 이 계약 때문에 204는 단순한 대역폭 편의 이상입니다. 성공적인 상태 변경과 표현 교체를 분리합니다.

HTTP/1.0은 사용자 에이전트에서의 연속성을 기술했다

1996년 5월에 발행된RFC 1945는 204를, 되돌려 보낼 새로운 정보가 없는 처리 완료된 요청으로 기술했습니다. 클라이언트가 사용자 에이전트라면 요청을 생성한 문서 화면을 변경해서는 안 됩니다.

이 문서는 스크립트와 기타 동작을 주요 사용 사례로 명시했습니다. 입력이 활성 문서를 밀어내지 않고도 효력을 발생할 수 있었습니다. 응답은 여전히 엔티티 헤더에 새로운 메타정보를 담을 수 있고, 그 정보는 이미 화면에 있는 문서에 적용되도록 되어 있었습니다.

따라서 두 가지 아이디어가 처음부터 존재했습니다. 첫째, 새로운 본문이 없다고 해서 완료 주장이 약해지지 않았습니다. 둘째, 기존 화면은 단순히 화면에 남아 있는 것이 아니라, 이를 보존하는 것이 의도된 동작이었습니다.

HTTP/1.0은 또한 204를 본문을 포함해서는 안 되는 응답으로 분류했습니다. 그 부재는 구조적이며, 우연히 선택된 0바이트 표현이 아니었습니다.

HTTP/1.1은 메시지 경계를 정확하게 만들었다

RFC 2068은 1997년에 화면 유지 모델을 유지하면서, 204 응답은 메시지 본문을 포함해서는 안 되며 헤더 필드 뒤 첫 빈 줄에서 끝난다고 명시했습니다.

RFC 2616은 1999년에 메타데이터 언어를 다듬었습니다. 서버는 요청을 처리했고, 엔티티 본문을 돌려줄 필요가 없으며, 요청된 변형과 관련된 갱신된 메타정보를 반환할 수 있었습니다. 사용자 에이전트는 그 메타데이터를 현재 문서에 적용하면서 현재 문서 화면을 유지해야 했습니다.

메서드 정의는 204를 완료된 분기로 사용했습니다. 결과를 기술하는 표현 없이 실행된 DELETE는 204를 반환할 수 있었습니다. PUT으로 성공적으로 수정된 기존 리소스는 결과 표현과 함께 200을 반환하거나, 표현 없이 204를 반환할 수 있었습니다.

여기서 중요한 대비가 확립되었습니다. 응답 본문이 없다고 해서 동작이 불확실성 쪽으로 물러나지 않았습니다. 메서드는 이미 완료 경계를 넘었던 것입니다.

204는 빈 200이 아니었다

길이 0의 200과 204는 같은 수의 응답 콘텐츠 옥텟을 운반할 수 있습니다. 그러나 같은 진술을 하지는 않습니다.

전형적인 200 응답은 콘텐츠를 담을 것으로 기대되며, 프레이밍이 길이를 0으로 말하더라도 그렇습니다. 204는 성공적인 결과에 필요한 콘텐츠가 없기 때문에 추가적인 응답 콘텐츠가 없다고 말합니다. 상태 코드는 그 부재에 이유를 부여하고, 일반적인 구성 요소에 어떤 프레이밍과 인터페이스 가정이 적용되는지 알려 줍니다.

이 구분은 클라이언트가 0바이트를 우연히 빠진 표현으로 취급하는 것을 막습니다. 또한 서버가 204를 내세우며 몰래 상태 문서를 덧붙이는 것을 막습니다.

부재에 유형이 있을 때 프로토콜은 더 신뢰할 수 있게 됩니다. 0은 데이터일 수 있습니다. 204는 제어 결과입니다.

헤더는 동작 이후의 상태를 기술했다

2014년의RFC 7231은 동작 이후의 참조를 더 명확하게 만들었습니다. 204 응답의 메타데이터는 요청된 동작이 적용된 이후의 대상 리소스와 선택된 표현을 가리킵니다.

PUT 예제는 간결하지만 결과가 큽니다. 성공적인 PUT이 ETag와 함께 204를 받는다면, 그 ETag는 대상 리소스의 새로운 표현을 식별합니다. 클라이언트는 문서를 다시 내려받지 않고도 편집기에서 문서의 버전 마커를 갱신할 수 있습니다.

본문은 없지만 결과의 식별자 역시 없지 않습니다. Date, 캐시 제어 및 기타 적용 가능한 필드는 여전히 동작 이후의 사실을 전달할 수 있습니다. “204는 아무것도 아니다”라며 모든 헤더를 버리는 클라이언트는 다음 조건부 저장에 필요한 바로 그 증거를 잃어버립니다.

이 구분은 ETag가 가정만으로 요청 페이로드에 묶이는 것도 막습니다. 응답 메타데이터는 원 서버 처리 이후의 선택된 표현을 명명합니다. 원 서버가 제출된 콘텐츠를 변환한다면, 반환된 식별자는 명세의 조건 하에서 결과 서버 상태에 관한 것입니다.

활성 화면은 유지되되, 학습할 수 있었다

문서 화면을 유지한다는 것이 무지 속에서 얼어 붙는다는 뜻은 아닙니다. 서버는 사용자 에이전트가 자체적인 성공 표시를 제공하고 새로운 또는 갱신된 응답 메타데이터를 활성 표현에 적용할 것이라고 가정합니다.

따라서 원 서버는 동작이 완료되었는지, 어떤 사후 메타데이터가 권위적이은지를 통제합니다. 사용자 에이전트는 성공을 로컬에서 어떻게 보여줄지, 응용 목적을 위해 다른 검색이 필요한지를 통제합니다.

이 분담은 두 가지 불필요한 전송을 피합니다. 서버는 작업 문서를 되돌려 보낼 필요가 없고, 클라이언트는 확인 페이지로 이동할 필요가 없습니다. 그럼에도 클라이언트는 ETag나 다른 메타데이터로 동시성 상태를 앞으로 이동할 수 있습니다.

인터페이스는 그 자리에 머무르며, 로컬 모델이 낡은 채로 있을 필요는 없습니다.

205는 반대쪽 사용자 인터페이스 분기를 그렸다

HTTP 205 Reset Content는 레지스트리에서 인접해 있지만 한 가지 결정적인 면에서 반대입니다. 성공적인 205 이후 사용자 에이전트는 요청을 유발한 문서 화면을 재설정하여 다음 입력 동작에 대비하도록 요구받습니다.

HTTP 204는 그 재설정을 요청하지 않습니다. 고전적인 저장 동작은 문서를 계속 편집할 수 있도록 남겨 둡니다. 204를 205로 취급하면, 서버가 그런 동작을 하나도 요청하지 않았는데도 로컬 작업이 지워지거나, 폼 상태가 초기화되거나, 포커스가 이동할 수 있습니다.

두 코드는 “둘 다 콘텐츠가 없다”는 분류가 얼마나 불충분한지 보여 줍니다. 콘텐츠 부재는 공유되지만, 인터페이스 통제는 아닙니다. 헤더가 끝난 뒤 활성 화면에서 무엇이 일어나야 하는지는 상태 시맨틱스가 결정합니다.

모든 본문 없는 성공을 하나의 일반적인 UI 분기로 매핑하는 구현은 프로토콜이 만든 구분을 그냥 버립니다.

202는 다른 시간 경계를 표시했다

HTTP 202 Accepted는 표면적으로 유사한 또 다른 응답입니다. 간결할 수 있고 최종 업무 결과를 전달하지 못할 수도 있습니다. 그러나 그 시간적 주장은 전혀 다릅니다. 202는 처리가 접수되었으나 완료되지 않았으며, 영원히 완료되지 않을 수도 있다고 말합니다.

HTTP 204는 요청이 성공적으로 처리되었음을 말합니다. “콘텐츠가 도착하지 않았다”는 이유로 재시도하면 이미 실행된 변경을 복제할 수 있습니다. 반대로 비동기 작업이 완료되기 전에 204를 보내는 것은 동작의 시간 경계를 거짓으로 말하며, 클라이언트에게 상태 모니터링 경로를 빼앗습니다.

이 차이는 반복이 결과를 낳는 동작—멱등성, 청구, 삭제, 게시 및 기타 모든 동작—에 중요합니다. 본문 길이는 완료의 증거가 아닙니다. 상태 코드가 증거입니다.

빈 네트워크 메시지는 커밋 선의 어느 쪽에도 놓일 수 있습니다. 202와 204는 클라이언트에게 어느 쪽인지 알려 줍니다.

헤더 섹션이 곧 전체 응답이었다

현재의RFC 9110은 204가 헤더 섹션의 끝에서 끝나며 콘텐츠나 트레일러를 포함할 수 없다고 명시합니다. 서버는 204 응답에서Content-Length를 보내서는 안 됩니다.

이 엄격한 프레이밍은 단지 미적 청결함 이상을 보호합니다. 지속 연결에서 콘텐츠를 금지하는 시맨틱스를 가진 응답 뒤에 나타나는 예상치 못한 바이트는 수신자마다 다르게 해석되거나 다음 메시지와 혼동될 수 있습니다. 경계에서의 파서 불일치는 무해해 보이는 성공을 연결 수준의 위험으로 바꿉니다.

따라서 JSON, 개행, 추적 푸터 또는 기본Content-Length: 0을 자동으로 덧붙이는 미들웨어는 상태 코드를 인식하는 동작이 필요합니다. 헤더가 끝나면 응답은 완전합니다.

콘텐츠 없음의 시맨틱스는 다음 메시지가 시작될 수 있는 위치로 강제됩니다.

휴리스틱 캐시 가능성이 메서드 규칙을 지우지 않았다

RFC 7231은 204를 기본적으로 캐시 가능한 것으로 기술했습니다. RFC 9110은 메서드 정의나 명시적 캐시 제어가 달리 말하지 않는 한, “휴리스틱하게 캐시 가능하다”는 더 정밀한 표현을 사용합니다.

이 문장은 쉽게 과잉 일반화됩니다. POST, PUT 또는 DELETE에 대한 모든 응답을 저장하고 이후 임의의 요청에 재사용할 수 있다는 뜻이 아닙니다.RFC 9111은 캐시 재사용을 메서드 시맨틱스, 캐시 키, 신선도, 명시적 제어에 묶어 둡니다.

흥미로운 캐시 대상은 종종 존재하지 않는 본문이 아니라 사후 응답 메타데이터입니다. 잘못된 요청 맥락에서 재사용하면 ETag나 정책 상태가 잘못된 동작에 붙을 수 있습니다.

따라서 원 서버는 특히 상태 변경 메서드에 대해 의도적인 캐시 제어를 내보내야 합니다. 중개자는 메서드를 인식하는 키를 보존해야 하며, “휴리스틱하게 캐시 가능한 상태 코드”를 보편적 허가로 취급해서는 안 됩니다.

콘텐츠 없음이 여전히 부족할 수 있다

204는 클라이언트가 올바르게 계속하기 위해 응답 표현을 필요로 하지 않을 때만 적절합니다. 업무 동작은 클라이언트가 실제로 필요로 하는 식별자, 영수증, 복구 토큰, 충돌 설명 또는 다음 단계 URI를 산출할 수 있습니다. 그 결과를 204 뒤에 숨기는 것은 우아한 미니멀리즘이 아니라 불완전한 응용 계약입니다.

사후 메타데이터로 충분한지 여부는 서버가 결정하지만, 그 결정은 클라이언트와 합의된 응용 프로토콜을 존중해야 합니다. HTTP는 204를 허용하지만, 생략된 모든 결과를 수용 가능하게 만들지는 않습니다.

마찬가지로, 로컬 화면이 정규화된 콘텐츠를 필요로 한다면 사용자 에이전트는 대상을 다시 가져오기로 결정할 수 있습니다. 상태 코드는 응답이 이동을 요구하지 않는다고 말할 뿐, 다른 검색이 금지된다고 말하지 않습니다.

최소 전송은 빠진 바이트가 진정으로 중복될 때만 작동합니다.

IANA는 매우 구체적인 부재를 보존한다

IANA HTTP 상태 코드 레지스트리는 204 No Content를 RFC 9110 섹션 15.3.5에 대응시킵니다. 등록은 이 좁은 주장 조합을 보존합니다.

동작은 성공했습니다. 이 응답에는 추가 콘텐츠가 없습니다. 메타데이터는 동작 이후의 리소스를 기술합니다. 현재 화면을 교체할 필요는 없습니다. 메시지는 헤더로 끝납니다.

이 주장 중 어느 것도 리소스가 비어 있거나, 없거나, 삭제되었다는 뜻이 아닙니다. 어느 것도 클라이언트가 헤더를 무시해도 된다고 말하지 않습니다. 어느 것도 인터페이스에 재설정을 요구하지 않습니다.

이름은 짧습니다. 보존된 시맨틱스는 아닙니다.

화면을 장악하지 않고 저장이 성공했다

HTTP 204는 절제의 프로토콜입니다. 원 서버는 동작을 완료했다는 것을 알지만, 확인 문서로 사용자의 다음 화면을 통제하려 들지 않습니다. 사용자 에이전트는 로컬 피드백과 계속 작업에 대한 책임을 유지합니다.

동시에 절제가 모호함을 의미하지는 않습니다. 상태 코드는 완료를 고정하고, 헤더는 사후 식별자를 운반하며, 프레이밍은 부재의 정확한 경계를 고정합니다.

이 얇은 결과가 유용해진 이유는 각 계층이 자신의 권한을 지켰기 때문입니다. 서버는 저장할 수 있었습니다. 클라이언트는 그 자리에 머물 수 있었습니다. 메타데이터는 앞서 나갈 수 있었습니다. 네트워크는 멈출 수 있었습니다.

페이지가 바뀌지 않은 이유는 프로토콜이 더 표시할 것이 없었기 때문이지, 아무 일도 일어나지 않았기 때문이 아닙니다.