Resumen

  • HTTP/1.0 ya definía 204 como una petición cumplida sin información nueva que mostrar. El agente debía conservar la vista del documento que produjo la petición.
  • “No Content” no significa que no haya estado ni metadatos. Los encabezados se refieren al recurso y a su representación seleccionada después de la acción; tras PUT, un ETag puede identificar la nueva versión guardada.
  • 204 termina con la sección de encabezados. No puede contener contenido ni trailers y HTTP actual prohíbe Content-Length. La ausencia es una frontera semántica.

El éxito no siempre requería otra página

Muchas interacciones tempranas unían dos hechos: terminaba una acción y aparecía un nuevo documento. Eso era natural para recuperar información o mostrar un resultado. Era innecesario al guardar y continuar trabajando.

Un editor no necesita recibir de vuelta todo el documento para saber que se guardó. Tampoco debería perder la superficie de trabajo en favor de una página de confirmación. El resultado útil es compacto: la acción terminó, esta es la nueva identidad de versión, continúe.

204 convirtió ese resultado en un tipo. No es un 200 cuyo cuerpo desapareció por accidente, sino un éxito cuya ausencia de contenido forma parte del acuerdo.

Por eso el código separa cambio de estado y sustitución de la representación visible.

HTTP/1.0 colocó la continuidad en el agente

El RFC 1945, de mayo de 1996, describió 204 como una petición cumplida sin información nueva que devolver. El agente no debía cambiar la vista que había generado la petición.

La especificación pensaba en scripts y otras acciones. Una entrada podía surtir efecto sin desplazar el documento activo. Los encabezados todavía podían aportar metainformación aplicable a ese documento.

Desde el principio convivían dos ideas: la falta de cuerpo no reducía la certeza del cumplimiento, y conservar la vista no era una casualidad de interfaz.

HTTP/1.0 también incluía 204 entre las respuestas que no podían tener cuerpo.

HTTP/1.1 fijó el final del mensaje

El RFC 2068 mantuvo el modelo en 1997 y dijo que 204 no incluye message-body. Termina en la primera línea vacía después de los encabezados.

El RFC 2616 refinó la metainformación en 1999. La petición estaba cumplida, el servidor no necesitaba enviar entidad y podía devolver datos actualizados asociados con la variante solicitada. El agente debía aplicarlos sin abandonar la vista.

Las definiciones de método situaron 204 tras la ejecución. DELETE ya aplicado podía usarlo sin representación descriptiva. PUT de un recurso existente podía responder 200 con resultado o 204 sin él.

La falta de cuerpo no devuelve la operación a la incertidumbre: ya cruzó el límite de confirmación.

Un 204 no es un 200 de cero bytes

Un 200 vacío y un 204 pueden llevar el mismo número de octetos de contenido. No hacen la misma afirmación.

Un 200 normal espera contenido, aunque el encuadre marque longitud cero. Un 204 dice que no hay contenido adicional porque el resultado exitoso no lo necesita. El estado explica el vacío y determina el encuadre y la respuesta de interfaz.

El cliente no debe interpretar cero bytes como una representación perdida. El servidor tampoco puede declarar 204 y añadir silenciosamente un documento de estado.

Cero puede ser un dato. 204 es un resultado de control.

Los encabezados describen el mundo posterior

El RFC 7231 aclaró en 2014 que los metadatos de 204 se refieren al recurso y a su representación seleccionada después de aplicar la acción.

Su ejemplo PUT muestra el valor. Si el 204 contiene ETag, identifica la nueva representación. El editor puede actualizar el marcador de versión sin descargar de nuevo el documento que acaba de guardar.

Falta el cuerpo, no la identidad del resultado. Date, controles de caché y otros campos siguen informando. Desecharlos porque “204 no contiene nada” elimina la evidencia necesaria para el próximo guardado condicional.

El ETag tampoco debe atribuirse automáticamente al payload de la petición. Identifica el estado seleccionado tras el procesamiento del origen.

La vista permanecía, pero podía actualizar su conocimiento

Mantener la vista no significa congelar el modelo local. El servidor presupone que el agente indicará el éxito mediante su propia interfaz y aplicará los nuevos metadatos a la representación activa.

El origen controla la finalización y los metadatos autorizados. El agente controla cómo muestra éxito y si necesita otra lectura por razones de aplicación.

Así se evitan dos transferencias: el servidor no hace eco del documento y el cliente no navega a una confirmación. Sin embargo, el ETag avanza el estado de concurrencia.

La pantalla se queda; su conocimiento no tiene que quedar obsoleto.

205 ordena la rama opuesta de interfaz

HTTP 205 Reset Content también carece de contenido, pero pide restablecer la vista que produjo la petición para preparar otra entrada.

204 no solicita ese borrado. En el guardado clásico deja el documento listo para seguir editando. Tratarlo como 205 puede limpiar campos, perder contexto o mover el foco sin mandato del servidor.

“Ambos sin cuerpo” no es una semántica suficiente. Comparten ausencia, no control de interfaz.

El componente que agrupa todo éxito sin contenido en una rama genérica elimina una diferencia deliberada del protocolo.

202 queda antes del límite temporal

HTTP 202 Accepted puede ser breve, pero el trabajo solo ha sido aceptado y quizá nunca se complete. Su promesa temporal es opuesta.

HTTP 204 declara cumplimiento. Reintentar porque no llegó cuerpo puede repetir una acción ya aplicada. Enviar 204 mientras sigue una tarea asíncrona miente y quita al cliente una vía de seguimiento.

La diferencia importa en pagos, borrados, publicaciones y cualquier efecto cuya repetición sea costosa. La longitud no demuestra finalización; el estado sí.

Una respuesta vacía puede existir antes o después del commit. 202 y 204 señalan el lado.

Los encabezados son toda la respuesta

El RFC 9110 dice que 204 termina al acabar la sección de encabezados y no puede tener contenido ni trailers. El servidor no debe enviar Content-Length.

La regla protege conexiones persistentes. Octetos inesperados pueden interpretarse de manera distinta o confundirse con el siguiente mensaje.

Middleware que añade automáticamente JSON, salto de línea, pie de trazas o Content-Length: 0 necesita conocer el estado. La respuesta está completa cuando terminan los encabezados.

El lugar donde comienza el siguiente mensaje materializa la ausencia.

La caché heurística conserva reglas de método

RFC 7231 llamaba a 204 cacheable por defecto. RFC 9110 lo llama heurísticamente cacheable, salvo reglas de método o controles explícitos.

No significa que todo POST, PUT o DELETE pueda guardarse y reutilizarse. El RFC 9111 sigue ligando uso a método, clave, frescura y directivas.

Lo almacenado suele ser metadato posterior, no un cuerpo inexistente. Reutilizarlo en el contexto equivocado puede unir un ETag a otra operación.

El origen debe enviar controles deliberados y la caché mantener claves conscientes del método.

A veces ningún contenido es demasiado poco

204 solo conviene si el cliente puede continuar sin representación de resultado. Una operación puede producir identificador, recibo, token de recuperación, explicación de conflicto o siguiente URI imprescindible.

Ocultarlo detrás de 204 no es minimalismo, sino contrato incompleto. HTTP permite omitir contenido; no vuelve aceptable cualquier omisión.

El agente también puede releer el recurso si necesita su forma canónica. El estado dice que la respuesta no exige navegación, no que otra lectura esté prohibida.

El transporte mínimo funciona cuando los bytes ausentes son realmente redundantes.

IANA registra una ausencia precisa

El registro IANA de estados HTTP asigna 204 No Content al RFC 9110, sección 15.3.5.

La acción tuvo éxito. No hay contenido adicional. Los metadatos hablan del estado posterior. La vista no tiene que ser reemplazada. El mensaje acaba en los encabezados.

Nada de eso dice que el recurso esté vacío, ausente o eliminado. Nada permite ignorar encabezados. Nada solicita reinicio.

El nombre es corto; la ausencia está rigurosamente definida.

El guardado terminó sin adueñarse de la pantalla

204 es una regla de moderación. El origen sabe que terminó, pero no controla la siguiente vista mediante una página de confirmación. El agente conserva la responsabilidad del feedback y de continuar.

Moderación no significa ambigüedad. El estado fija la finalización, los encabezados fijan identidad y el encuadre fija frontera.

Cada capa mantiene autoridad: el servidor guarda, el cliente permanece, el metadato avanza y la red se detiene.

La página no cambió porque no había más que mostrar, no porque no hubiera ocurrido nada.