Summary

  • Según la revisión 05 de Byte Range PATCH, un servidor sin soporte de PUT parcial puede ignorar Content-Range y reemplazar el recurso entero con el trozo enviado.
  • El formato message/byterange incorpora el intervalo a un documento PATCH de una sola parte. Si el intervalo es desconocido, el servidor debe rechazarlo con 400 o 422.
  • La longitud declarada en una parte tiene que coincidir con el intervalo. Cuando se admiten huecos en un archivo, el servidor debe impedir que salgan datos sin inicializar.

El ejemplo del borrador reduce el problema a una operación que cabe en una servilleta. El archivo contiene 0123456789 y un fin de línea. Se quiere poner wxyz entre las posiciones 2 y 5. El resultado esperado es 01wxyz6789 con ese mismo fin de línea. Si la petición acaba en un servidor que interpreta el cuerpo de PUT como el recurso nuevo, el resultado puede ser solo wxyz. El cliente había señalado las posiciones; el archivo desapareció bajo una instrucción que el receptor podía pasar por alto.

El texto del IETF sitúa el fallo en el contrato de la petición. PUT con Content-Range exige soporte específico. En su ausencia, el servidor puede aplicar la sustitución normal de PUT. No hay una alarma inherente en el encabezado que obligue al receptor a tratar cuatro bytes como parte de un objeto mayor. El daño aparece precisamente cuando ambos lados creen haber hecho algo razonable.

La alternativa del borrador usa PATCH y un tipo de documento con significado propio. message/byterange sirve para un intervalo; multipart/byteranges permite varios, y application/byteranges propone una codificación binaria. El servidor que conoce ese tipo recibe la operación parcial como parte del cuerpo que ha decidido procesar. Si desconoce el formato, la respuesta correcta es negarse antes de tocar el recurso. La diferencia para el operador es decisiva: una incapacidad visible se puede corregir; una sustitución silenciosa deja una versión falsa.

Un intervalo tiene límites, y deben comprobarse

Cada parte de la modificación identifica un tramo contiguo. Sin posición conocida, el servidor debe devolver 400 o 422. Si la parte declara Content-Length, ese valor debe coincidir exactamente con el tamaño del intervalo. Dejar pasar un desacuerdo obliga al servidor a inventar qué bytes pertenecen a la operación. La misma precisión protege un flujo de tamaño todavía desconocido: Content-Offset indica dónde empieza la escritura cuando no se sabe dónde acaba.

Hay un borde físico que un API no puede disimular. Escribir justo al final amplía el archivo. Escribir más allá deja un hueco sin contenido definido. El borrador aconseja rechazar esta segunda clase de escritura. Si el servidor permite archivos dispersos, debe impedir la exposición de memoria sin inicializar y debería llenar los huecos con ceros. Una prueba que solo compruebe el código HTTP y nunca lea el archivo terminado perderá el fallo esencial.

La sección 4 trata otra decisión: si una subida interrumpida se revierte o conserva lo recibido. El cliente puede expresar Prefer: transaction=atomic o transaction=persist; el servidor debería confirmar lo aplicado con Preference-Applied. Esa preferencia administra el estado de una petición incompleta. Primero hay que saber si la petición modifica un intervalo o reemplaza el objeto entero.

La RFC 5789 permite anunciar tipos PATCH con Accept-Patch. Falta una traza pública que ejecute PUT con intervalo y PATCH message/byterange sobre copias idénticas en distintos servidores, guardando bytes iniciales y finales, respuesta y ETag. Esa prueba distinguiría el diseño del comportamiento real.

Borrador y estado · RFC 5789 · RFC 9110