Resumen

  • Range localiza los bytes que faltan, pero no demuestra que la representación actual sea la que produjo los bytes guardados.
  • If-Range conserva la petición parcial solo ante una coincidencia fuerte; ante una discrepancia hace que el servidor ignore el rango y entregue el objeto actual completo.
  • La regla evita otra petición y el ensamblaje entre versiones, sin prometer soporte de rangos, recepción íntegra, almacenamiento, autenticidad ni corrección del contenido.

El desplazamiento sabía dónde, no de cuál versión

Un cliente conserva la primera mitad de un paquete después de una caída. Cuando vuelve, puede pedir desde el desplazamiento exacto donde terminó. Ese número es correcto incluso si, durante la ausencia, el paquete fue reconstruido. En tal caso señala una posición válida dentro de una secuencia nueva. Añadir la respuesta al prefijo viejo crearía una combinación que el servidor nunca publicó.

La nueva conexión no podía heredar por sí sola la identidad de la anterior. El problema tampoco se resolvía con la longitud: dos versiones pueden medir lo mismo y diferir en cada bloque. HTTP necesitaba llevar dos datos distintos. Range expresaba la geografía del fragmento; un validador expresaba la continuidad temporal de la representación seleccionada.

RFC 2068 incorporó If-Range a HTTP/1.1 en 1997. El documento observó que un GET de rango con una precondición ordinaria podía fallar si la entidad cambiaba. El cliente tendría entonces que hacer otra petición para conseguir el cuerpo actual completo. La nueva cabecera ofrecía un atajo: si nada cambió, enviar lo que falta; si cambió, enviar la entidad nueva entera.

En 1999, RFC 2616 mantuvo esa bifurcación. Una etiqueta coincidente conducía a la subparte mediante 206 Partial Content. Una etiqueta distinta conducía a toda la entidad mediante 200 OK. El resultado falso no era un juicio de error sobre la lectura. Solo cancelaba el ahorro que dependía de continuar una copia antigua.

La misma petición aceptaba fragmento o reemplazo

Una solicitud podía incluir:

Range: bytes=5242880-
If-Range: "build-a19"

El cliente estaba ofreciendo un acuerdo muy concreto. Aceptaría menos bytes únicamente si "build-a19" seguía identificando con fuerza la representación actual. Si la comparación fallaba, quería el objeto actual completo. Por eso el servidor debía ignorar Range y el cliente debía sustituir, no prolongar, su copia parcial.

La diferencia con otras condiciones es estructural. If-Match puede bloquear una operación y terminar en 412 Precondition Failed. If-None-Match puede evitar un cuerpo con 304 Not Modified. If-Range ya declara que 200 con el cuerpo completo es útil. Su condición no decide si GET está autorizado o si el recurso existe; decide si el ahorro parcial sigue siendo seguro.

RFC 7233 separó las peticiones de rango en 2014 y endureció la explicación. Un cliente no debe enviar If-Range sin Range. El servidor lo ignora si no hay rango o si el objetivo no admite la operación. Si el validador coincide, debería procesar el rango; si no coincide, debe ignorarlo. La cabecera acorta el camino a la copia actual, pero no obliga a fabricar una respuesta parcial.

RFC 9110 conserva hoy el orden de evaluación. Cuando GET contiene ambas cabeceras, una condición verdadera y un rango aplicable llevan a 206. En otro caso, se omite Range y la respuesta normal es 200. Un error detectable antes, una redirección o la falta de soporte conserva su prioridad. La condición no gobierna todo el intercambio.

Para soldar bytes no bastaba con “equivalente”

Los validadores débiles permiten declarar que dos representaciones son suficientemente equivalentes aunque sus bytes no sean idénticos. Esa flexibilidad puede servir para validar una caché o evitar una recarga visual sin importancia. Es incompatible con la operación de colocar un intervalo a continuación de otro. Allí cualquier diferencia desplaza o altera el resultado.

RFC 7232 define el validador fuerte para comparaciones donde cambian los datos observables, incluidas las respuestas parciales. If-Range no admite una ETag marcada como débil. Una fecha Last-Modified solo puede emplearse si el cliente no tiene etiqueta y la fecha cumple la exigencia de fuerza.

Las fechas ilustran el peligro. La resolución del reloj puede ser menor que la frecuencia de publicación. Dos modificaciones distintas pueden compartir marca temporal. Además, la fecha de If-Range se compara de forma exacta con Last-Modified, a diferencia de la comparación anterior-o-igual de If-Unmodified-Since. Una fecha dudosa debe cerrar el camino parcial y favorecer la copia completa.

Una ETag fuerte tampoco es automáticamente un hash. Es opaca para el cliente. El compromiso protocolario es no reutilizarla en datos observables diferentes de las representaciones pertinentes de ese recurso. No autentica al servidor, no asegura que el contenido sea correcto y no permite afirmar que otra URL con la misma cadena ofrece el mismo objeto. RFC 2616 dejó explícito ese límite entre URI distintas.

Coincidir era el comienzo del rango

Después de una coincidencia aún quedan controles. El servidor puede no implementar la unidad pedida. La sintaxis puede ser inválida o la posición quedar fuera de la longitud actual. Si el rango es compatible, válido y satisfacible, 206 Partial Content contiene una o varias partes. Content-Range ubica una parte única; multipart/byteranges contiene varias. Si ninguna posición se solapa con la representación, la respuesta puede ser 416 Range Not Satisfiable.

Esos metadatos tienen funciones distintas. Content-Range dice que cierto cuerpo ocupa, por ejemplo, los bytes 5.242.880 a 6.291.455 de una longitud conocida. No certifica el origen de los bytes anteriores. La ETag compartida sostiene la continuidad de versión, mientras que el historial del cliente sostiene la recepción y el ensamblaje.

Así se entiende la asimetría del riesgo. Una discrepancia innecesaria hace viajar otra vez el objeto completo: es cara y visible. Una coincidencia falsa puede dejar un artefacto híbrido que parece completo y pasa a otra capa sin alarma. El protocolo sacrifica eficiencia cuando no tiene evidencia suficiente para conservarla.

La caché debía recordar más que huecos

Una caché puede almacenar un 200 incompleto o varias respuestas 206. Cuando decide unirlas, asume responsabilidad por su procedencia. RFC 7234 permite guardar contenido incompleto solo si la caché comprende Range y Content-Range. Permite combinar tramos únicamente cuando todos comparten el mismo validador fuerte.

La continuidad de coordenadas no sustituye esa regla. Tener cubiertos del byte cero al último no impide que cada zona venga de una edición diferente. Al combinar, la caché también debe mantener coherentes las cabeceras y no presentar como completo un objeto que continúa incompleto.

La especificación vigente de caché, RFC 9111, conserva el mismo reparto. Una respuesta incompleta puede completarse con otra petición de rango; no puede reutilizarse como total hasta serlo. Una respuesta parcial debe estar marcada como 206. La cabecera condicional no guarda ni ensambla: solo suministra una pieza de evidencia para decidir la forma de una respuesta.

Por eso una auditoría necesita conservar la solicitud objetivo, los campos de negociación, el rango, el validador anterior, el actual, el tipo de comparación, el estado, Content-Range y la huella del objeto montado. Ningún elemento aislado cuenta toda la historia. El servidor demuestra qué envió; el cliente demuestra qué conservó e incorporó.

Una identidad temporal sin registro universal

La solución no exigió reservar identificadores mundiales de versiones ni congelar recursos mientras regresaban clientes interrumpidos. El origen emitía su validador. El cliente lo vinculaba a su fragmento. El servidor comparaba el presente. La caché custodiaba sus piezas. Cada participante conservaba la decisión que podía justificar.

El campo compartido solo preguntaba si valía todavía el privilegio de pedir menos. Cuando la respuesta era negativa, el cliente seguía recibiendo la versión actual. Esa modestia hizo interoperable la reanudación sin convertir el estado de una descarga en autoridad central sobre la publicación.

Los RFC establecen la semántica, no la conducta de productos contemporáneos. No prueban que una etiqueta real sea fuerte, que una CDN la conserve, que el destino soporte rangos o que el resultado se escriba sin fallos. Para eso hacen falta capturas del intercambio, historial de selección y validadores, intervalos recibidos y verificación independiente del objeto final.