Resumo

  • O HTTP/1.0 já usava 204 para uma requisição cumprida sem informação nova a exibir. O agente deveria manter a visualização do documento que causou a requisição.
  • No Content não significa ausência de estado ou metadados. Cabeçalhos descrevem o recurso e sua representação selecionada depois da ação; após PUT, um ETag pode identificar a nova versão salva.
  • 204 termina junto com os cabeçalhos. Não pode conter conteúdo nem trailers, e o HTTP atual proíbe Content-Length. O vazio é uma fronteira do protocolo.

Sucesso nem sempre precisava abrir outra página

Muitas interações iniciais uniam conclusão e novo documento. Isso fazia sentido para recuperação e resultados que mereciam representação. Para salvar e continuar, era desperdício.

Um editor não precisa receber o documento inteiro para provar o salvamento, nem perder a área de trabalho para uma confirmação. O resultado útil é pequeno: ação concluída, nova identidade de versão, continue.

204 tipificou esse resultado. Não é 200 com corpo perdido, mas sucesso cuja ausência de conteúdo integra o contrato.

O código separa mudança de estado da troca de representação visível.

HTTP/1.0 preservou a continuidade

O RFC 1945, de maio de 1996, definiu 204 como requisição cumprida sem nova informação. Um agente não deveria mudar a visualização que gerou a requisição.

Scripts e ações podiam produzir efeito sem deslocar o documento ativo. Cabeçalhos ainda podiam trazer metainformação aplicável a ele.

Ausência de corpo não diminuía a conclusão; a permanência da tela não era acidente. Essas ideias nasceram juntas.

O HTTP/1.0 também proibia corpo em 204.

HTTP/1.1 fixou o término na linha vazia

O RFC 2068 preservou o modelo em 1997 e determinou que 204 não inclui message-body, terminando na primeira linha vazia após os campos.

O RFC 2616 refinou em 1999: o servidor cumpriu a requisição, não precisa devolver entidade e pode enviar metainformação atualizada associada à variante solicitada. O agente mantém a visualização e aplica os dados.

DELETE executado sem representação descritiva podia usar 204. PUT bem-sucedido podia retornar 200 com resultado ou 204 sem ele.

O corpo ausente não deixa a operação pendente. O limite de conclusão já foi cruzado.

204 não é um 200 de zero bytes

Um 200 vazio e um 204 podem carregar zero octetos. Não fazem a mesma afirmação.

200 normalmente prevê conteúdo, ainda que o framing marque comprimento zero. 204 diz que nenhum conteúdo adicional é necessário. O status explica a ausência e define suposições de framing e interface.

O cliente não precisa imaginar que uma representação se perdeu. O servidor não pode declarar 204 e anexar um documento silencioso.

Zero pode ser dado; 204 é resultado de controle.

Cabeçalhos descrevem o estado após a ação

O RFC 7231 esclareceu em 2014 que metadados de 204 se referem ao recurso e à representação selecionada depois da ação.

No exemplo PUT, um ETag em 204 identifica a nova representação. O editor atualiza sua versão sem baixar novamente o que acabou de salvar.

O corpo falta, não a identidade. Date, controles de cache e outros campos mantêm significado. Descartá-los porque “não há nada” destrói a prova para o próximo salvamento condicional.

O ETag descreve o estado após processamento, não automaticamente o payload pedido.

A tela ficava, o conhecimento avançava

Preservar a visualização não congela o modelo local. O servidor presume que o agente mostrará sucesso pela própria interface e aplicará metadados à representação ativa.

A origem controla conclusão e metadados autorizados. O agente controla feedback e eventual nova leitura.

Evita-se eco do documento e página de confirmação, enquanto o ETag avança a concorrência.

A superfície permanece sem ficar desatualizada.

205 escolhe a ramificação oposta

HTTP 205 Reset Content também não tem conteúdo, mas pede que a visualização seja restaurada para nova entrada.

204 não pede limpeza. No salvamento, o documento continua editável. Tratá-lo como 205 pode apagar campos, contexto ou foco sem autorização.

“Sem corpo” não resume a semântica. A ausência é comum; o controle da interface não.

Uma ramificação genérica elimina a distinção criada pelo protocolo.

202 está antes da fronteira temporal

HTTP 202 Accepted informa aceitação, não conclusão, e a ação pode nunca ocorrer.

HTTP 204 declara cumprimento. Repetir por ausência de corpo pode duplicar efeito; retornar 204 enquanto trabalho assíncrono continua mente sobre o commit.

Isso importa para pagamento, exclusão, publicação e qualquer ação sensível à repetição. Tamanho não prova conclusão; status prova.

Uma resposta vazia pode estar antes ou depois do commit. 202 e 204 distinguem.

Os cabeçalhos são a resposta inteira

O RFC 9110 determina que 204 termina ao fim dos cabeçalhos, não possui conteúdo nem trailers e não pode enviar Content-Length.

Octetos inesperados em conexão persistente podem ser interpretados como parte da próxima mensagem ou causar divergência entre parsers.

Middleware que acrescenta JSON, nova linha, rodapé ou Content-Length: 0 deve conhecer o status. Terminados os cabeçalhos, terminou a resposta.

A posição da próxima mensagem garante o No Content.

Cache heurístico não apaga regras do método

RFC 7231 chamava 204 de cacheável por padrão; RFC 9110 diz heuristically cacheable, salvo método ou controles contrários.

Não autoriza guardar qualquer POST, PUT ou DELETE. O RFC 9111 ainda exige método, chave, frescor e diretivas.

O item relevante pode ser metadado posterior, não corpo. Reutilizá-lo no contexto errado liga ETag a outra operação.

Origem e cache devem preservar controles e consciência de método.

Às vezes nenhum conteúdo é insuficiente

204 serve quando o cliente continua corretamente sem representação de resultado. Uma operação pode gerar identificador, recibo, token, conflito ou próxima URI indispensável.

Omitir isso não é minimalismo, mas contrato incompleto. HTTP permite ausência, não qualquer omissão.

O agente pode reler o recurso se precisar da forma canônica. O status dispensa navegação nesta resposta, não proíbe GET posterior.

Transporte mínimo exige bytes realmente redundantes.

A IANA registra uma ausência exata

O registro de status HTTP da IANA liga 204 No Content ao RFC 9110 15.3.5.

Ação concluída, sem conteúdo adicional, metadados posteriores, visualização preservada, fim nos cabeçalhos.

Não significa recurso vazio, inexistente ou removido; não autoriza ignorar cabeçalhos nem pede reset.

O nome é curto; a ausência, precisa.

O salvamento acabou sem tomar a tela

204 é contenção. A origem sabe que terminou, mas não domina a próxima tela com confirmação. O agente mantém feedback e continuidade.

Contenção não é ambiguidade. Status fixa conclusão, cabeçalhos fixam identidade, framing fixa limite.

O servidor salva, o cliente permanece, metadados avançam e a rede para.

A página não mudou porque não havia mais o que mostrar, não porque nada ocorreu.