Resumen

  • FEAT reunía las extensiones FTP documentadas en una consulta sin argumentos, evitando que el cliente tuviera que probar órdenes con posibles efectos.
  • Una lista positiva conforme cerraba el inventario del servidor, pero un 500 o 502 no cerraba la cuestión: extensiones anteriores a FEAT podían seguir funcionando.
  • OPTS aceptaba una configuración para una orden posterior; no autenticaba al usuario ni certificaba que aquella orden o su transferencia terminarían bien.

El coste oculto de tantear un protocolo

La extensibilidad suele describirse como una ventaja abstracta. Para un cliente real es también un problema de conocimiento. FTP nació con un conjunto básico de órdenes, pero la práctica añadió mecanismos que los servidores adoptaron a ritmos distintos. Conocer la especificación de una extensión no decía nada concluyente sobre el servidor que acababa de responder al puerto de control.

Probar la nueva orden era una forma de descubrimiento, aunque defectuosa. Consumía un turno por cada posibilidad y convertía una pregunta en una acción. RFC 2389 señaló que una orden enviada únicamente para saber si era reconocida podía tener un efecto no deseado. El sistema carecía de un plano descriptivo separado del plano operativo.

FEAT llenó ese hueco. El cliente enviaba la palabra sin parámetros. El servidor que la entendía respondía con su inventario de extensiones. El cliente podía decidir qué intersección existía entre ese inventario y su propia implementación. No había un negociador central que decidiera el uso: había una descripción común y una decisión local.

Esa arquitectura reducía tráfico, pero su valor principal era epistemológico. Saber qué mecanismo está disponible no exige todavía activarlo. Al separar ambos actos, el protocolo podía producir una prueba más estrecha y, por ello, más fiable.

La lista tenía bordes precisos

Una respuesta con funciones comenzaba como respuesta 211- de varias líneas. Cada función aparecía en una línea propia con un único espacio inicial. 211 End cerraba el bloque. El espacio impedía que un contenido válido pudiera confundirse con el terminador. La gramática hacía posible analizar el resultado sin adivinar dónde acababa.

El texto de apertura era libre; las líneas de función no. La etiqueta podía coincidir con una orden o describir una propiedad distinta. La extensión que introducía la etiqueta definía también sus parámetros. El orden carecía de significado y ni siquiera tenía que permanecer estable entre dos consultas.

El cliente debía tolerar etiquetas desconocidas. Ese requisito evitaba que el futuro pareciera un error de sintaxis al software del pasado. Ver una función nueva solo significaba que el servidor había incorporado un documento que el cliente todavía no conocía. El resto de la conversación podía continuar sobre las funciones compartidas.

Ni FEAT ni OPTS tenían que anunciarse en la propia lista. El primero se demostraba por la respuesta recibida; el segundo era un requisito de cualquier servidor que implementara FEAT. La respuesta no pretendía ser una transcripción de todo el estado del servidor, sino un inventario concreto de extensiones.

Una asimetría diseñada por la historia

RFC 2389 exigía a un servidor con FEAT que enumerase todas las extensiones FTP debidamente documentadas que soportaba más allá de RFC 959 y del propio mecanismo. Para ese servidor, la respuesta positiva tenía una propiedad fuerte: era completa. Una extensión ausente de la lista conforme podía considerarse no soportada.

No ocurría lo mismo cuando FEAT fallaba. Un servidor que no conocía la orden devolvía 500 o 502. Muchas extensiones ya existían antes de 1998, por lo que una implementación antigua podía admitir alguna y, al mismo tiempo, ignorar el mecanismo creado para enumerarla. En ese caso el cliente tal vez debía volver a una prueba específica.

Incluso un servidor que comprendía FEAT pero no tenía funciones adicionales podía responder con el mismo error, aunque la respuesta preferida fuera un 211 de una sola línea. Desde fuera, «no sé hacer el inventario» y «sé hacerlo, pero está vacío» podían ser indistinguibles.

La consecuencia era sutil y potente. Una respuesta bien formada permitía razonar por ausencia dentro de ella. La falta de respuesta no permitía razonar por ausencia fuera de ella. El protocolo no obligó a los despliegues anteriores a adquirir retroactivamente una semántica que nunca habían emitido.

Elegir una opción no era consumir el servicio

OPTS resolvía un segundo problema. Algunas extensiones no eran binarias: admitían parámetros o comportamientos. El cliente podía indicar la orden objetivo y las opciones que deseaba para una ejecución posterior. La definición concreta quedaba en manos del documento de esa orden.

Un 200 confirmaba que la orden objetivo y las opciones eran reconocidas y apropiadas. 501 indicaba un defecto permanente mientras no cambiara el estado; 451, una condición temporal del servidor. Ninguna respuesta afirmaba que la orden futura hubiera sucedido.

RFC 3659 mostró la diferencia con MLST. Su línea de capacidad enumeraba los hechos de archivo disponibles y marcaba con asterisco los que se enviarían por defecto. OPTS MLST cambiaba el conjunto usado después por MLST y MLSD. Pedir un hecho no soportado no obligaba a inventarlo, y algunos hechos no predeterminados podían ser costosos de obtener.

Había, por tanto, una cadena: el servidor conoce un hecho; lo anuncia; lo selecciona por defecto o acepta la selección del cliente; lo aplica cuando corresponde a una entrada; y finalmente lo devuelve. La interfaz conserva esas etapas porque tienen responsables y fallos diferentes.

La seguridad seguía necesitando su propia prueba

Cuando RFC 4217 aplicó TLS a FTP, utilizó la infraestructura de FEAT. El servidor anunciaba AUTH TLS, PBSZ y PROT. La lista hacía visible una ruta hacia la protección, pero no protegía nada por sí misma.

Todavía eran necesarios AUTH TLS, la aceptación 234, el intercambio TLS, la configuración de protección, la evaluación del certificado y, según el caso, la autenticación del usuario FTP. Una etiqueta de capacidad no decía qué identidad presentaría el servidor ni si la política del cliente la aceptaría. Tampoco afirmaba que la conexión de datos posterior usaría la protección adecuada.

RFC 7151 repitió la estructura con HOST. La presencia de HOST en la lista declaraba soporte para servidores virtuales. Elegir uno podía restablecer el entorno de autenticación, y el nombre tenía que contrastarse con la identidad del certificado. Descubrir la función, seleccionar el contexto y confiar en la identidad eran tres actos distintos.

IANA protegía el nombre, no aprobaba el resultado

El crecimiento de extensiones llevó a RFC 5797 y al registro de Órdenes y Extensiones FTP de IANA. Su cometido era evitar que una misma etiqueta acabara significando dos cosas. Registraba el nombre, el código FEAT, la descripción, el tipo de orden, la expectativa de conformidad y la referencia.

La especificación advirtió que estar inscrito no demostraba que una extensión estuviera «aprobada». Podía bastar una especificación pública permanente o una implementación en clientes y servidores generalmente disponibles. Las entradas históricas seguían visibles para evitar colisiones. Los códigos de reserva no estaban destinados a ser devueltos como funciones reales.

El registro era una capa de unicidad semántica. No observaba el servidor concreto, no verificaba su configuración y no concedía permiso al usuario. Confundir esos ámbitos convertiría una tabla de coordinación en una autoridad operativa que el propio documento rechazaba.

La lista exponía una superficie limitada

RFC 2389 reconoció que el inventario podía facilitar deducciones sobre un servidor. Sin él, un observador podía tantear cada orden, aunque esa conducta quizá quedara más expuesta en los registros. El texto aceptó la divulgación acotada porque el descubrimiento activo no hacía desaparecer la información: solo la obtenía con más ruido y riesgo.

La lección no exige publicar todas las capacidades de todos los sistemas. Exige definir qué afirma cada superficie. Una lista debe usar nombres estables, tolerar novedades y decir lo suficiente para que el cliente elija. Las decisiones de identidad, autorización, recursos y resultado deben permanecer allí donde puedan comprobarse.

RFC 2389 convirtió una secuencia de apuestas en una conversación. Primero el servidor describía el repertorio. Luego el cliente elegía. Finalmente el sistema ejecutaba y producía sus propias respuestas. La lista ayudaba a decidir; nunca tuvo autoridad para declarar el desenlace.

Fuentes