Resumen

  • Upload-Offset confirma en draft-ietf-httpbis-resumable-upload-12 qué prefijo de la representación procesó el recurso temporal y cuál ya no necesita retransmisión.
  • Un 409 Conflict por desplazamientos distintos protege la secuencia; el progreso reconciliado todavía no prueba finalización, digest correcto, escaneo seguro, autorización actual ni compromiso del recurso objetivo.

Tras una caída, el cliente recordó 60 megabytes. El servidor respondió que había procesado 64. El código de reintento interpretó los cuatro megabytes de diferencia como una anomalía transitoria y volvió a enviar el fragmento desde 60.

El servidor lo rechazó con 409. Esa negativa salvó la representación.

Los cuatro megabytes habían llegado y habían sido procesados antes de que se perdiera la respuesta. Si el servidor hubiera aceptado la memoria del cliente, habría duplicado una franja en medio del objeto. Si el cliente hubiese impuesto su estado local, habría convertido ausencia de recibo en ausencia de procesamiento.

La revisión 12 de Resumable Uploads for HTTP, publicada el 6 de julio de 2026, diseña precisamente esta reconciliación. Es un Internet-Draft activo del grupo HTTP, con destino Standards Track y caducidad el 7 de enero de 2027. No es todavía RFC, informe de despliegue ni prueba de interoperabilidad. Su modelo resulta útil porque no intenta que un solo contador narre todo el ciclo de vida.

El recurso temporal no es el objeto solicitado

La petición inicial apunta a un recurso con semántica de aplicación: crear, sustituir o procesar algo. Para hacer reanudable el cuerpo, el servidor crea otro recurso, temporal y exclusivo de una representación. Allí se consulta el progreso, se anexan partes o se cancela.

La separación asigna responsabilidades. El recurso de carga conserva continuidad de bytes. El recurso objetivo decide si la operación solicitada tiene sentido y cuál respuesta produce. La existencia de una URI temporal no demuestra que exista el objeto final; la capacidad de escribir en ella tampoco concede por sí sola derecho a consumar la acción original.

El servidor puede retirar la URI al completar o conservarla un tiempo para que un cliente que perdió la última respuesta verifique el estado. Por eso un 404 posterior no permite inferir éxito o fracaso sin conocer la política de retención. La evidencia decisiva es la respuesta final y el registro de la operación objetivo.

El desplazamiento vive por encima del transporte

El borrador define el offset como bytes de representación procesados por la aplicación del recurso de carga. Un transporte puede haber recibido y confirmado paquetes que todavía esperan en buffers. Reanudar desde el ACK de red mezclaría entrega con incorporación al estado del servidor.

La respuesta Upload-Offset sí ofrece una garantía estrecha: el prefijo procesado no tendrá que retransmitirse. El cliente puede liberar memoria o descartar segmentos locales que guardaba para recuperación. Esa promesa tiene valor económico y operacional.

No promete que el objeto pasó una política, llegó a la base definitiva, se replicó, quedó publicado o producirá un resultado. Tampoco sustituye un digest. Un sistema honesto etiqueta el dato como «prefijo procesado por este recurso temporal», no como «carga válida».

El offset no puede disminuir. Si el servidor pierde parte de su estado, debe desactivar el recurso y rechazar interacciones futuras. Inventar un nuevo punto de reanudación mantendría una apariencia de disponibilidad a cambio de corromper el significado del recibo.

Longitud y finalización son coordenadas distintas

La longitud puede conocerse desde el principio o descubrirse cuando termina una fuente en streaming. El desplazamiento puede alcanzar exactamente esa longitud y la carga seguir incompleta. El protocolo no permite deducir una decisión de la igualdad numérica.

La finalización se expresa con Upload-Complete. El cliente puede enviar todos los bytes en solicitudes previas y cerrar después con un PATCH vacío. También puede mantener abierto un flujo cuya longitud ya se ha determinado. Solo la declaración explícita cambia el estado.

En respuestas de creación o anexo, el valor verdadero indica que ya se aplican las semánticas del recurso objetivo. Incluso puede aparecer cuando ese objetivo decide responder temprano, antes de transferirse toda la representación. Completar no significa siempre «recibimos todos los bytes»; significa que el intercambio salió del régimen temporal según la decisión del objetivo.

El 409 conserva una única línea de montaje

Cada PATCH lleva el offset que el cliente cree vigente. Si no coincide, el servidor devuelve su propia vista y la marca de completitud. El cliente debe detenerse, leer el estado, comprobar que sigue usando la misma representación fuente y escoger una continuación definida.

No hay soporte para anexos paralelos al mismo recurso. El servidor serializa anexos y cancelación, evitando que dos cuerpos ocupen el mismo punto. Pero la serialización no elimina la pérdida de respuestas. Dos clientes o dos procesos reintentando con memoria distinta siguen necesitando una regla de propietario y una identidad fuerte de la fuente.

El conflicto es, por tanto, un recibo de desacuerdo. No acusa por sí mismo corrupción ni identifica al culpable. Su autoridad es negativa y precisa: no añadas estos bytes en esta posición hasta reconciliar el estado.

104 anuncia reanudación, no éxito

El código provisional 104 puede entregar pronto la URI temporal y sus límites. También puede informar avances mientras se procesa la solicitud. Si la conexión se corta después, el cliente conoce dónde preguntar y continuar.

Un mensaje provisional no es la respuesta final del objetivo. La creación optimista empieza a enviar todo inmediatamente y confía en recibir el 104 a tiempo. Si un intermediario lo elimina o la interrupción llega antes, el servidor puede tener bytes sin que el cliente tenga una coordenada para recuperarlos.

La creación cuidadosa primero obtiene una URI con cuerpo vacío y luego transfiere. Añade una ida y vuelta, pero asegura la referencia antes de gastar ancho de banda. Ninguna estrategia convierte el soporte de reanudación en aceptación de la operación.

La representación ensamblada debe volver a ser juzgada

Un contador correcto no prueba integridad. Los digests de contenido o representación cubren bytes definidos por reglas diferentes y requieren una comparación explícita. La carga puede progresar perfectamente y acabar con un resumen incorrecto.

También puede atravesar un control fragmentario. Una firma peligrosa dividida entre dos PATCH no aparece si el escáner considera cada mensaje un archivo completo. La revisión de seguridad debe actuar sobre la representación reunida antes de ejecutarla, publicarla o entregarla a otro procesador. Los metadatos siguen siendo entrada no confiable.

La URI de carga es el identificador capaz de modificar el estado. Debe ser difícil de adivinar y accesible solo a clientes autorizados. Pero el secreto del enlace no sustituye autenticación, autorización, expiración ni registro de quién anexó cada tramo.

El derecho de empezar puede caducar antes de terminar

Una carga grande puede sobrevivir horas o días. Durante ese periodo cambian roles, cuotas, procesos de aprobación y obligaciones de conservación. La autorización comprobada en la creación no necesariamente sigue vigente en el commit.

El borrador advierte sobre esa distancia entre comprobación y uso. Antes de finalizar, el servidor debe volver a verificar que el principal puede realizar la acción solicitada. Así, una URI que todavía acepta bytes no obliga al objetivo a aceptar el objeto.

La cadena verificable queda formada por ocho hechos: entrega de transporte; prefijo procesado; offset reconciliado con longitud; finalización explícita; integridad y política de contenido; autorización vigente; compromiso del objetivo; efecto posterior. El salto entre hechos requiere un nuevo recibo.

Fuentes y límites

El paquete congelado incluye la revisión 12, su historial, el espacio de trabajo HTTP y los RFC sobre semántica HTTP, caché, HTTP/1.1, HTTP/2, QUIC, Digest Fields, PATCH, Problem Details y Content-Disposition. Describe diseño y límites, no adopción, rendimiento, incidentes ni comportamiento de empresas concretas.

Fuentes