Resumen

  • HTTP 206 confirma la entrega correcta de uno o varios rangos declarados de una representación seleccionada; por sí solo no demuestra que rangos obtenidos por separado formen un objeto completo.
  • La reanudación y el ensamblaje en caché necesitan un validador fuerte compartido, cobertura exacta de intervalos y una comprobación final de la representación.
  • En una respuesta 206, Content-Length suele medir el cuerpo de ese mensaje, mientras que Content-Range ubica los bytes e indica la longitud completa de la representación.
  • Un recibo de ensamblaje debe conservar la identidad de versión y cada intervalo aceptado, no tratar el contador total como prueba suficiente.

Imaginemos una descarga de un archivo de datos de enrutamiento desde un almacén de objetos. La conexión se corta a mitad de camino. Antes de reanudarla, el origen sustituye el archivo por una exportación más reciente del mismo tamaño aparente. Ambas solicitudes devuelven 206, llegan todos los rangos pedidos y el contador alcanza la longitud prevista. Sin embargo, el archivo reconstruido combina el principio de una versión con el final de otra porque ningún validador fuerte vinculó los intentos.

Es una hipótesis sobre disciplina operativa, no un incidente atribuido a un proveedor. HTTP ofrece los mecanismos para evitarla. El error consiste en pedir al estado de una respuesta parcial que demuestre una propiedad del conjunto completo.

El éxito de un rango tiene un significado limitado

RFC 9110 define 206 Partial Content como el cumplimiento correcto de una solicitud de rango mediante la transferencia de una o varias partes de la representación seleccionada. El servidor afirma que entregó los intervalos descritos. No afirma que el cliente ya posea toda la representación.

El destinatario debe examinar Content-Type y cada Content-Range para conocer las partes incluidas y decidir si necesita más solicitudes. En un único rango, Content-Range señala el intervalo inclusivo y normalmente la longitud total. Content-Length cuenta los octetos del contenido de la respuesta 206 presente. Confundirlos convierte una respuesta correcta en una falsa señal de finalización.

En respuestas multipartes, los rangos pueden llegar en otro orden; el servidor puede agruparlos o excluir los no satisfacibles. La cobertura debe calcularse a partir de los intervalos devueltos, no del orden solicitado, el número de respuestas ni una barra de progreso.

La continuidad pertenece a la representación, no a la URL

Una URL estable no garantiza bytes estables. La negociación de contenido, un despliegue, la hora de generación o una actualización del origen pueden cambiar la representación sin modificar la URI. Una reanudación segura necesita demostrar que los fragmentos antiguos y nuevos pertenecen a la misma versión.

If-Range protege esa frontera. El cliente envía un rango condicionado por un validador. Si aún coincide, el servidor puede devolver la parte pedida. Si no coincide, ignora Range y envía la nueva representación completa. RFC 9110 prohíbe un ETag débil en If-Range: la comparación ha de distinguir representaciones aptas para combinarse byte a byte.

Por eso, un 200 después de If-Range no es un fallo de eficiencia que deba forzarse de nuevo a 206. Es la señal de que el fragmento anterior ya no se puede ampliar con seguridad. El cliente debe sustituir el estado anterior por el objeto completo recién recibido.

La caché asume la misma obligación

RFC 9111 permite a una caché completar una respuesta incompleta con transferencias de rango. Solo puede combinar los rangos si todos comparten el mismo validador fuerte y cumple las reglas de contenido parcial.

Ni el porcentaje de aciertos ni los bytes almacenados prueban esa condición. Hay que conservar la clave y el contexto de negociación, el validador de cada intervalo, la actualización de cabeceras y si la respuesta ensamblada está fresca, revalidada o autorizada para servirse caducada. Un gestor de descargas, un espejo o una pasarela tiene el mismo problema en cuanto conserva fragmentos, aunque no use la palabra caché.

Comprobar la integridad en el nivel correcto

RFC 9530 separa Content-Digest, calculado sobre el contenido de un mensaje HTTP, de Repr-Digest, calculado sobre los datos de toda la representación seleccionada. En un 206, el primer resumen puede verificar el segmento recibido; el segundo puede verificar el objeto reconstruido a través de varias solicitudes o conexiones.

El resumen no sustituye al validador. El validador demuestra continuidad de versión; Repr-Digest comprueba los bytes finales; la tabla de intervalos acredita que no hay huecos ni solapamientos ocultos por un total. Estos campos tampoco definen autenticación, autorización o privacidad. La cuestión de R063 es más acotada: si los bytes recuperados forman una representación coherente.

Crear un recibo de ensamblaje por rangos

El recibo se abre al aceptar el primer fragmento. Registra la URI, el método, las cabeceras que influyen en la selección, la codificación, el tipo de medio, la longitud completa, el validador fuerte, la hora y la procedencia: origen, intermediario o almacenamiento local.

Por cada parte conserva el intervalo realmente devuelto, el estado, el validador, la fuente, el estado de caché y, cuando exista, el resumen del segmento. Una tabla normalizada evita que los solapamientos inflen el progreso y mantiene visibles los huecos. Se rechaza cualquier fragmento cuyos metadatos o validador no coincidan con la identidad congelada.

El recibo solo se cierra cuando los intervalos cubren exactamente la representación y los bytes reconstruidos coinciden con el Repr-Digest esperado u otra huella obtenida de forma independiente. Si el validador cambia, desaparece o resulta ambiguo, se descarta el ensamblaje y se recupera una representación completa. El coste adicional protege la afirmación verdaderamente importante: el objeto procesado existió como una sola versión.

Fuentes