Resumen

  • ALLO permitía declarar cuántos bytes lógicos necesitaría un archivo antes de ejecutar STOR o APPE, incluida una medida adicional para registros o páginas.
  • El código 202 mantenía la interoperabilidad con servidores que no necesitaban preasignar: era una terminación positiva que decía que la orden era superflua, no un recibo de espacio comprometido.
  • La evidencia de almacenamiento aparecía en la operación posterior, sus respuestas finales y el objeto resultante; confundir una autorización para continuar con capacidad garantizada desplazaba el riesgo a un momento más caro.

El número llegó antes que el archivo

Un cliente sabe que va a transmitir un fichero grande. Todavía no ha abierto la conexión de datos, pero ya conoce una cifra. En vez de descubrir el límite tras gastar tiempo de red, envía ALLO y declara el tamaño. La idea parece la de un almacén: avisar cuántas cajas vienen para que alguien reserve estanterías.

FTP nació, sin embargo, entre sistemas que no administraban el almacenamiento del mismo modo. Para unos, apartar capacidad por adelantado podía ser una condición real. Para otros, los bloques se asignaban durante la escritura y no existía una operación equivalente. Exigir una promesa idéntica habría convertido una diferencia local en una incompatibilidad de red.

El RFC 354, de 1972, ya describía ambas posibilidades. ALLOCATE podía ser requerido por ciertos servidores para reservar suficiente espacio para un archivo nuevo. El argumento era un entero decimal en bytes según el tamaño de byte elegido, y después debía llegar STORE o APPEND. Pero los servidores que no exigían conocer el máximo de antemano debían tratar la orden como una operación nula.

No era un descuido. La especificación daba al servidor una salida explícita: aceptar la conversación sin fingir que había realizado una acción inútil. De ese modo, el cliente podía seguir usando una secuencia común frente a arquitecturas de almacenamiento diferentes.

En 1980, el RFC 765 afinó el mensaje. El primer entero expresaba bytes lógicos. Si el archivo usaba estructura de registros o páginas, podía aparecer un segundo entero para el tamaño máximo de registro o página, separado mediante espacio, R, espacio. Un servidor interesado solo en el segundo dato debía aceptar un valor ficticio en el primero y descartarlo.

La sintaxis revelaba su contexto. El cliente no estaba midiendo sectores libres ni bloqueando una cuota universal. Describía el archivo según la representación que FTP estaba usando. El servidor debía traducir esa descripción a su sistema local, si tal traducción era necesaria.

Una clase positiva con dos historias distintas

El RFC 959 conservó en 1985 la forma ALLO seguida de un entero y, opcionalmente, R y otro entero. También reiteró que los servidores sin necesidad de una declaración máxima previa debían tratarla como NOOP.

Las respuestas hacen visible el diseño. Una ejecución exitosa de ALLO que no ofrece información nueva al proceso usuario puede producir 200. Si un servidor no implementa la acción porque carece de relevancia para ese sistema —el RFC usa ALLO como ejemplo— todavía se desea una terminación positiva. Así un cliente sencillo sabe que puede continuar. La respuesta asignada es 202, con “No storage allocation necessary” como texto ilustrativo.

La frase general de 202 es “Command not implemented, superfluous at this site”. Las dos mitades importan. “No implementada” describe la ausencia de la acción; “superflua” evita convertir esa ausencia en fracaso. El código no certifica una reserva alternativa. Certifica que la secuencia puede avanzar sin ella.

Esto distingue 202 de 502, que corresponde a una acción no específica del sitio que no está implementada, y de 504, que señala un parámetro no disponible. Los diseñadores no pusieron todos los “no hago esto” en el mismo cajón. Preguntaron si omitir la acción impedía o no el objetivo del usuario.

Tampoco conviene fabricar una certeza a partir de 200. La propia explicación dice que se utiliza cuando la ejecución exitosa no aporta información nueva. Puede existir un efecto local valioso, incluida una reserva en un sistema que la necesite, pero el número por sí solo no enumera bloques, plazo, cuota, competencia ni durabilidad. Para conocer esos detalles hace falta evidencia de implementación.

STOR era la prueba que ALLO no podía ser

Después de ALLO tenía que llegar STOR o APPE. STOR ordena aceptar los datos de la conexión y guardarlos con el nombre indicado. Si ya existe un archivo, la especificación dispone su sustitución; si no existe, su creación. Ahí entran en juego el camino de datos, la autorización, el espacio disponible y los límites reales.

La conversación tiene etapas. 125 indica que la conexión de datos ya está abierta y comienza la transferencia. 150 anticipa que se abrirá. Ambas son respuestas preliminares: informan de movimiento, no de desenlace. Las terminaciones positivas 226 o 250 aparecen después, mientras que fallos de conexión, procesamiento, nombre o almacenamiento tienen sus propios códigos.

452 significa que la acción solicitada no se tomó por espacio insuficiente en el sistema. 552 informa que la acción sobre el archivo se abortó al exceder una asignación, por ejemplo la del directorio o conjunto de datos. Es perfectamente coherente recibir antes un 202: el servidor dijo que no necesitaba reservar de antemano, no que el futuro STOR fuera infalible.

El orden temporal cambia el valor de la prueba. Antes del flujo, el cliente posee una estimación. Tras 202, posee permiso protocolario para seguir. Tras 150, sabe que el servidor intenta iniciar la transferencia. Solo una finalización adecuada y la verificación del archivo sostienen una afirmación más fuerte sobre lo almacenado.

El RFC 3659 expresa una cautela semejante al definir permisos para listados legibles por máquina. Que aparezca permiso de escritura nunca garantiza que la orden vaya a funcionar; limitaciones locales, como el espacio disponible, todavía pueden causar el fallo. Es un ejemplo posterior de la misma economía de evidencia: aptitud anunciada y resultado ejecutado ocupan lugares diferentes.

Lo opcional no tenía por qué quedar encerrado

El RFC 1123 clasificó el soporte servidor de ALLO como opcional. A la vez exigió que el programa de usuario ofreciera QUOTE, capaz de enviar cualquier cadena al servidor y mostrar todas sus respuestas. Su explicación menciona SITE y ALLO como funciones específicas u opcionales a las que un usuario todavía podría acceder.

Esa combinación daba margen a tres participantes. El servidor decidía qué mecanismo local necesitaba. El cliente mantenía un núcleo interoperable sin codificar cada particularidad. El usuario podía cruzar el límite con una instrucción explícita. La estandarización no consistía en imponer una única política de disco, sino en mantener un canal común para negociar diferencias.

El registro IANA de comandos y extensiones FTP sigue registrando ALLO como el comando básico “Allocate” y referencia el RFC 959. Esto ayuda a identificar el término. No demuestra que un servidor concreto lo implemente, que el sitio aparte espacio ni que una transferencia haya alcanzado el disco.

Reconstruir la secuencia, no decorar un estado

Un registro operacional debería guardar la línea exacta de ALLO, los valores declarados, TYPE, STRU, el código y el texto de respuesta. Reducir 200 y 202 a un mismo indicador verde elimina justo la decisión que interesa: acción local completada frente a acción considerada innecesaria.

La correlación debe continuar con STOR o APPE. Hay que observar si la conexión de datos se abrió, cuántos bytes pasaron, si surgió un aborto, cuál fue la respuesta final y qué objeto quedó. Tamaño, suma de comprobación, cuota y espacio libre aportan pruebas que la señal preparatoria no contenía.

Incluso una finalización positiva de FTP no define por sí sola retención indefinida, replicación o recuperabilidad. Cuando esas propiedades importan, se comprueban por separado. La disciplina consiste en formular la afirmación al nivel de la evidencia: 202 prueba que el servidor permitió continuar considerando superflua la reserva; no prueba que el contenido ya tuviera un hogar.

Fuentes