Resumen

  • Un campo que no puede analizarse como Structured Fields, un digest cuya longitud no puede corresponder al algoritmo declarado y un valor bien formado que no coincide son tres fronteras distintas.
  • El tipo de problema ayuda a escoger la investigación siguiente, pero no demuestra quién causó el fallo, qué alcance de bytes se comparó ni si es seguro repetir la operación.

El centro de operaciones recibió tres avisos en pocos minutos. El primero contenía una cabecera que el analizador de Structured Fields no podía leer. El segundo declaraba SHA-512, pero llevaba un valor de longitud imposible. El tercero estaba bien formado y tenía la longitud esperada, aunque difería del cálculo del servidor.

Los tres terminaron en la misma cola: integrity_failure=true. El mismo procedimiento volvió a serializar la cabecera, cambió el algoritmo y reenvió la solicitud. En un caso corrigió el mensaje. En otro ocultó un error del emisor. En el tercero repitió una operación cuyo resultado de negocio seguía siendo desconocido.

La clasificación genérica no simplificó la realidad; destruyó la información necesaria para actuar. El borrador HTTP Problem Types for Digest Fields propone justamente separar estos estados mediante tipos de problema legibles por máquinas. Su revisión 06 está fechada el 24 de junio de 2026 y vence el 26 de diciembre de 2026. En el corte del 2 de octubre, Datatracker lo mostraba en la cola del RFC Editor, a la espera de un primer editor, con Mike Bishop como Area Director responsable y la revisión IANA en estado de acciones reconocidas. Aspira a Proposed Standard, pero aún no tiene número RFC. El avance editorial no prueba que un sistema concreto implemente sus tipos.

El error de sintaxis ocurre antes del valor

RFC 9530 construye los campos Digest sobre Structured Fields, hoy definidos por RFC 9651. Antes de comparar un digest, el receptor debe poder analizar la estructura: nombres de algoritmo, valores binarios, parámetros y miembros. Si esa gramática falla, todavía no existe una pareja utilizable que el validador pueda declarar válida o inválida.

El borrador aclara que digest-invalid-values no es el tipo destinado a un fallo de análisis de Structured Fields. Esa separación parece pequeña, pero asigna responsabilidades. Una sintaxis rota puede proceder de la serialización, del transporte de cabeceras o de una reescritura. Su remedio es recuperar un campo canónico y entender dónde dejó de ser analizable.

Marcarla como «digest incorrecto» puede inducir al cliente a recalcular una y otra vez el mismo contenido, cuando el problema está en comillas, delimitadores, bytes o transformación de la cabecera. También puede ocultar una incompatibilidad de parser detrás de una falsa narrativa criptográfica.

Un valor imposible sí nombra al cálculo del emisor

digest-invalid-values entra después de que el campo pueda analizarse. El valor no podría haber sido generado por el algoritmo declarado: una longitud incompatible es el ejemplo evidente. Sus entradas pueden incluir algorithm, header y un reason legible por personas.

Este resultado concentra la investigación en el cálculo o la codificación del lado que produjo el valor. Repetir la solicitud sin modificarlo probablemente fallará de nuevo. Pero tampoco autoriza a aceptar automáticamente la siguiente versión. El nuevo valor aún debe calcularse sobre el alcance correcto, llegar intacto y superar las decisiones de aplicación.

El texto humano de reason ayuda a diagnosticar, no debe convertirse en una clave de control estable. Puede variar entre implementaciones, idiomas o versiones. La automatización debe usar el tipo estructurado y conservar la explicación para operadores, sin derivar autoridad de coincidencias textuales.

Una no coincidencia empieza donde acaba la forma

digest-mismatched-values supone que el valor es utilizable para una comparación. El servidor calcula su propio digest y obtiene otro resultado. La extensión identifica el algoritmo, el valor proporcionado y el campo. Deliberadamente no revela el digest calculado por el servidor, para evitar que la respuesta se convierta en un oráculo.

Eso define un límite probatorio. La respuesta acredita una desigualdad desde el punto de vista del componente que contestó. No revela la secuencia exacta de bytes que ese componente usó, no identifica al causante y no permite reconstruir la comparación completa.

El borrador observa que un intermediario podría haber modificado la solicitud sin intención y que el emisor podría volver a enviarla si el problema fue temporal. Son posibilidades. Un emisor que calculó sobre el alcance equivocado produce el mismo síntoma. También una transformación legítima, un acuerdo distinto sobre codificación o una corrupción. Convertir «podría ser» en «fue el proxy» es atribución sin evidencia.

Content, representación y contenido no codificado

El miembro header está presente porque el nombre del campo es parte de la afirmación. Content-Digest cubre contenido HTTP. Repr-Digest se refiere a la representación seleccionada. Los content codings y transformaciones pueden cambiar los bytes entre ambos puntos. El borrador separado Unencoded-Digest, todavía sin categoría de RFC en la fecha del estudio, añade otra referencia para contenido no codificado.

Un SHA-256 puede estar perfectamente calculado y ser irrelevante para la capa que el receptor valida. Si la plataforma de telemetría conserva solo algoritmo y resultado, pierde si el fallo ocurrió en contenido, representación o una variante no codificada. La cifra permanece exacta y el hecho deja de serlo.

La solución no es imponer un único alcance a todos los componentes. Es conservar el alcance declarado, el punto de validación y las transformaciones conocidas. El operador puede entonces distinguir una corrupción real de una comparación entre realidades distintas.

Varios diagnósticos no forman una jerarquía

Una solicitud puede llevar varios campos Digest o de preferencia. El borrador permite que problemas parecidos aparezcan varias veces. Los miembros de extensión son opcionales y su ausencia no tiene significado especial. Un servidor puede omitir detalle por política, implementación o seguridad.

Por ello, el primer elemento de una matriz no es «la causa raíz». El orden no concede prioridad, y la ausencia de un segundo elemento no demuestra que no exista otro fallo. Un cliente que corrige el primer registro y reintenta puede entrar en una secuencia donde cada intento descubre una condición que ya estaba presente.

La respuesta también es un Problem Details de RFC 9457. Su tipo identifica una clase; sus extensiones aportan contexto. El miembro JSON status, si está presente, es orientativo y puede no coincidir con el estado HTTP de la respuesta recibida si intervino un intermediario. El cuerpo no redefine el método ni el resultado de la aplicación.

Ninguna de las tres clases concede permiso de repetición

RFC 9110 conserva la regla decisiva. Las operaciones idempotentes admiten reintento automático con más seguridad porque repetir la intención tiene el mismo efecto previsto. Una solicitud no idempotente no debería repetirse automáticamente salvo que el cliente sepa que su semántica real es idempotente o pueda demostrar que la primera no se aplicó. Un proxy no debe repetir automáticamente una solicitud no idempotente. Tampoco conviene repetir de nuevo un reintento automático fallido.

Los ejemplos del borrador incluyen PUT y POST. El tipo de problema no cambia esas propiedades. Una sintaxis rota podría haber sido rechazada pronto en una arquitectura, mientras que en otra un componente lateral ya creó una reserva o un registro. Un mismatch recibido como 400 no certifica que ningún efecto ocurrió en todo el grafo distribuido.

La autoridad de repetición puede proceder de una clave de idempotencia, una condición, un identificador de transacción o una consulta durable del estado. Si no existe, el resultado debe quedar como desconocido y pasar a reconciliación. digest-mismatched-values no es una abreviatura de «no ejecutado».

Un modelo mínimo que no destruya la diferencia

Las capas de realidad de Heng Lu permiten nombrar el error de diseño. La cabecera y su digest son afirmaciones simbólicas sobre bytes. El parser produce un estado sintáctico. El validador produce un resultado de cálculo. El tipo de problema comunica una observación. El reintento es una acción nueva. La aplicación y el usuario viven en capas posteriores.

Una especificación inicial mínima conserva identificador de operación, método, destino, intento, autoridad de idempotencia, campo, algoritmo, resultado de parseo, resultado de forma, resultado de comparación, punto de validación, estado HTTP, tipo de problema y recibo de aplicación. No necesita capturar todo el sistema; sí debe impedir que una etapa rellene los resultados de las demás.

Running-Code Primacy exige pruebas separadas. Romper la gramática sin cambiar el contenido. Entregar una longitud imposible. Entregar una longitud correcta con bytes distintos. Mezclar varios campos. Omitir extensiones. Cambiar su orden. Perder una respuesta después de un efecto. Repetir un POST con y sin clave. La salida correcta conserva estados desconocidos y detiene la automatización cuando falta autoridad.

La taxonomía del borrador no añade complejidad innecesaria. Recupera distinciones que una etiqueta genérica había borrado. El trabajo de liderazgo consiste en asegurarse de que esas distinciones sobrevivan desde el parser hasta la decisión operativa.

Fuentes