Resumen

  • El reinicio original coordinaba una posición del emisor con otra del receptor y podía conservar el estado de almacenamiento y transformación necesario para continuar.
  • REST STREAM simplificó la marca a un número de octetos omitidos en la transferencia siguiente. Ese número identificaba un lugar, no una versión del archivo.
  • El ejemplo de RFC 3659 comprueba por separado que el archivo remoto no cambió. Sin esa condición, aceptar el desplazamiento no impide ensamblar partes de versiones diferentes.

El servidor aceptó 802816, no la historia del archivo

Una transferencia se rompe tras 802816 octetos. El cliente vuelve, establece TYPE I, envía REST 802816 y recibe 350. La orden RETR posterior empieza más adelante.

La respuesta confirma que el servidor guardó el parámetro para la próxima operación. No compara el prefijo local con el objeto remoto ni certifica que el nombre remoto conserve sus bytes anteriores. Si el archivo fue sustituido por otro bastante largo, el protocolo puede entregar un sufijo nuevo y producir un híbrido sin ninguna infracción de encuadre.

Las primeras marcas respetaban dos sistemas distintos

RFC 765 ya definía la recuperación como vuelta a un punto de control. REST no iniciaba datos: posicionaba el lado servidor y debía ir seguido por la orden de servicio interrumpida.

La abstracción era necesaria. FTP conectaba máquinas con tamaños de palabra, codificaciones, finales de línea y estructuras de registro distintos. El byte lógico del archivo no tenía por qué coincidir con el byte de transferencia. TYPE, STRU y MODE decidían qué secuencia cruzaba la red.

RFC 959 mantuvo los modos Stream, Block y Compressed. Los dos últimos daban formato al flujo y podían introducir bloques de reinicio distinguibles de los datos. El emisor creaba una marca útil para su sistema; el receptor la relacionaba con su propia posición almacenada. La interoperabilidad no exigía que ambos llamaran igual al punto.

Guardar una posición implicaba guardar realidad

RFC 1123 corrigió la respuesta 110: ssss codifica la posición del emisor y rrrr la correspondiente del receptor. Cada cadena podía ser privada, porque más tarde la interpretaría el mismo sistema que la generó.

Antes de anunciar su coordenada, el receptor debía llevar los datos previos a almacenamiento estable. De lo contrario, la marca sobreviviría a un fallo que hubiese borrado precisamente el progreso prometido.

También podía hacer falta estado interno. En TYPE A, un receptor puede convertir CR LF de la red en un LF local. Si la marca cae entre ambos caracteres, debe recordar que CR ya fue consumido. Una cifra de disco no basta para reconstruir esa transición.

Por eso RFC 1123 añadió 554 para una posición inaplicable y 555 para una discrepancia de TYPE o STRU. Una marca bien formada no obliga a que el archivo parcial siga siendo compatible.

STREAM sustituyó el marcador por una cuenta

El mecanismo era completo, pero costoso de implementar. RFC 1123 observó en 1989 que Restart, ABOR y Block mode eran funciones robustas útiles pero poco extendidas, y dejó REST fuera del conjunto mínimo. No es una medición de los despliegues actuales.

En Stream mode no hay hueco para una marca explícita: parecería contenido. RFC 3659 normalizó entonces el valor decimal de REST STREAM como la cantidad de octetos que no se enviarán al principio de la transferencia siguiente.

El cliente descubre esa función mediante FEAT, definido por RFC 2389. La declaración REST STREAM demuestra comprensión de la extensión, no inmutabilidad del objeto solicitado.

La representación sigue afectando al número. RFC 3659 calcula 1830 octetos para un texto con TYPE I y 1942 con TYPE A, porque la convención CR-LF altera el flujo. El desplazamiento pertenece a lo que se transmitiría bajo los parámetros actuales; no siempre es el índice nativo del archivo almacenado.

Para reanudar una subida, SIZE comunica cuánto quedó correctamente recibido y guardado según esa representación. La longitud ayuda a colocar la escritura, pero no autentica los octetos que ya existen.

La norma escribió la precondición en voz alta

El ejemplo de REST 802816 en RFC 3659 empieza indicando que la operación anterior usó TYPE I y que se verificó que el archivo del servidor no había cambiado desde entonces. La continuidad de versión llega desde fuera de REST.

En una descarga, el cliente decide cómo unir el sufijo con su parte local. En una subida, el servidor inserta datos en un objeto existente y las condiciones son más rígidas. El resultado queda indefinido si no se está completando la transferencia fallida, si la marca no coincide con el final almacenado o si el nuevo contenido no alcanza al menos el tamaño anterior. Si un servidor permite APPE, debe comportarse como STOR en la posición indicada.

350 deja una promesa pendiente

REST debe ser la última orden antes de RETR o STOR. Un valor puede recibir 350 y fallar solo cuando la orden posterior intenta aplicarlo. Si esa orden no llegó a transmitirse, el cliente prudente repite REST; no presupone que el servidor conserve el parámetro a través de cualquier conversación.

El estado real de recuperación está repartido entre el archivo parcial, los parámetros, la capacidad anunciada, la persistencia, el desplazamiento, la secuencia de órdenes y la comprobación de versión. Reducirlo a un entero oculta los elementos que evitan una mezcla silenciosa.

Límites de la evidencia

RFC 765 aporta el origen; RFC 959, los modos; RFC 1123, las posiciones emparejadas y el almacenamiento estable; RFC 2389, el descubrimiento; RFC 3659, STREAM, SIZE y las restricciones. No ofrecen prevalencia contemporánea ni garantizan versiones remotas. Reiniciar FTP no equivale a autenticar, calcular un hash, tomar una instantánea ni transferir exactamente una vez.