Resumo

  • FEAT permitiu consultar extensões documentadas sem experimentar cada comando; OPTS permitiu selecionar opções para um comando que viria depois.
  • Uma resposta positiva e conforme era um inventário completo, mas uma resposta 500 ou 502 não provava ausência: extensões anteriores a FEAT podiam continuar implementadas.
  • Anúncio de capacidade, aceitação de opção, identidade, autorização, conclusão do comando e efeito da transferência eram registros independentes.

Quando perguntar significava agir

O FTP básico da RFC 959 não ficou congelado. Comandos e mecanismos adicionais surgiram, e cada implementação os adotou no seu próprio ritmo. O cliente que conhecia uma extensão ainda precisava descobrir se o servidor do outro lado também a conhecia.

Testar o próprio comando parecia um método simples. A RFC 2389 expôs o problema: além de produzir uma sequência de trocas, um comando emitido apenas para verificar suporte poderia causar um efeito indesejado. A pergunta sobre capacidade utilizava a mesma superfície reservada à ação.

FEAT criou uma leitura anterior à ação. Sem argumento, o comando solicitava a lista de extensões suportadas. O cliente passava a decidir a partir da interseção entre o que o servidor anunciava e o que seu próprio software entendia. Cada extensão continuava responsável por definir o significado de seu rótulo e de seus parâmetros.

Esse desenho não transferiu poder decisório a uma tabela. Ele reduziu a camada comum ao que era preciso para descobrir: uma gramática, nomes e um limite de resposta. A escolha permanecia no cliente; o uso, sujeito ao servidor.

A gramática tornou a lista verificável

Uma lista não vazia vinha em uma resposta 211- de várias linhas. Cada recurso ocupava uma linha iniciada por exatamente um espaço, e 211 End encerrava o bloco. O espaço não era cosmético: impedia que uma linha de recurso fosse confundida com a linha final.

O texto inicial era livre, mas as linhas seguintes tinham estrutura. O rótulo podia ser o nome de um comando ou de outra propriedade. Os parâmetros eram definidos pelo documento que introduzia o recurso. A ordem não carregava significado e podia variar de uma consulta para outra.

Um cliente também precisava aceitar rótulos desconhecidos. Um servidor mais novo não estava errado por saber algo que o cliente antigo ignorava. O cliente podia deixar o item de lado e continuar usando o subconjunto comum. Assim, a extensibilidade não transformava o futuro em erro para o passado.

Nem FEAT nem OPTS apareciam na lista. Uma resposta diferente de 500 ou 502 já demonstrava o primeiro; o segundo era obrigatório para qualquer implementação de FEAT. A resposta descrevia apenas o domínio que lhe cabia.

A lista positiva fechava uma pergunta; o erro não fechava a outra

Em um servidor que implementava FEAT, todas as extensões FTP devidamente documentadas e suportadas além das RFCs 959 e 2389 tinham de aparecer. Por isso, a resposta positiva conforme era completa. Uma extensão ausente daquela lista podia ser tratada como não suportada naquele servidor.

Mas o erro 500 ou 502 indicava apenas que o servidor não reconhecia FEAT. Várias extensões haviam sido implantadas antes de existir um mecanismo para listá-las. Um servidor antigo poderia compreender uma delas e ainda assim rejeitar a consulta. O cliente, se precisasse manter compatibilidade, poderia fazer o teste específico.

Até o servidor que conhecia FEAT e não tinha extensão alguma podia usar 500 ou 502, embora a resposta preferida fosse um 211 de uma linha. Para o cliente, ausência de inventário e inventário vazio podiam ser praticamente indistinguíveis.

Essa assimetria impede um atalho comum. Uma resposta completa permite interpretar a ausência dentro dela. Não receber a resposta não autoriza inventar ausência fora dela. O protocolo deu peso à evidência disponível sem atribuir significado retrospectivo aos sistemas mais antigos.

OPTS definia o cenário da próxima ordem

Algumas extensões ofereciam alternativas. OPTS deixava o cliente indicar um comando-alvo e as opções desejadas. A extensão correspondente definia a sintaxe e o efeito concretos.

200 confirmava que alvo e opções eram reconhecidos e adequados. 501 registrava um problema permanente se nenhum estado mudasse. 451 apontava uma condição temporária do servidor. Nenhum deles afirmava que o comando-alvo já havia sido executado.

Na RFC 3659, a linha MLST podia enumerar fatos de arquivo disponíveis e marcar com asterisco os enviados por padrão. OPTS MLST mudava o conjunto usado nas respostas posteriores de MLST e MLSD. Fatos solicitados que não fossem suportados ou não se aplicassem ao arquivo podiam ser omitidos, e alguns fatos fora do padrão podiam ser caros para o servidor gerar.

Há uma diferença entre saber produzir um fato, oferecê-lo, selecioná-lo por padrão, aceitar um pedido e entregá-lo para um objeto específico. O mecanismo preservava essa sequência em vez de ocultá-la atrás de uma única bandeira de suporte.

Anunciar TLS ainda não criava TLS

A RFC 4217 usou FEAT para o FTP protegido por TLS. Um servidor compatível anunciava AUTH TLS, PBSZ e PROT. A lista mostrava que a rota de negociação existia. Não estabelecia a sessão protegida.

O cliente ainda precisava enviar AUTH TLS, receber 234, completar o handshake, configurar a proteção, validar a identidade apresentada no certificado e cumprir a autenticação FTP exigida. O anúncio não concedia permissão ao usuário e não garantia que um canal de dados futuro seria protegido ou concluiria uma transferência.

A RFC 7151 repetiu o padrão com HOST. O rótulo anunciava suporte a hosts virtuais, mas a escolha podia redefinir o ambiente de autenticação. O nome selecionado ainda precisava ser comparado à identidade do certificado. Encontrar uma porta, escolher a porta e confiar em quem está atrás dela não são a mesma prova.

O registro evitava colisões; não distribuía aprovação

Em 2010, a RFC 5797 criou o registro de Comandos e Extensões FTP da IANA. Seu objetivo era evitar que nomes de comandos ou de recursos ganhassem significados conflitantes. O registro reuniu nome, código FEAT, descrição, tipo, expectativa de conformidade e referência. Entradas históricas permaneceram para impedir reutilização ambígua.

O texto negou expressamente que o registro demonstrasse “aprovação”. Uma especificação pública permanente ou uma implementação em clientes e servidores geralmente disponíveis poderia justificar uma entrada. Códigos em minúsculas podiam ser meros espaços reservados, não itens que o servidor devesse anunciar.

A função do registro era manter nomes únicos e compreensíveis. A função do servidor era declarar sua implementação. A política local decidia quem podia agir. O protocolo em execução mostrava o que aconteceu. Promover o registro a árbitro de qualidade ou a prova de implantação seria ampliar sua autoridade para além da necessidade técnica que o criou.

Divulgação limitada era melhor do que sondagem por efeito

A RFC 2389 reconheceu que o inventário revelava capacidades do servidor. Sem FEAT, um interessado poderia sondar os comandos individualmente, embora isso talvez chamasse mais atenção nos registros. Os autores não consideraram a diferença grave o suficiente para retirar o mecanismo.

O compromisso não era transparência ilimitada. Era uma superfície descritiva limitada, suficiente para interoperar sem transformar toda pergunta em operação. Cada extensão ainda precisava tratar seus próprios riscos de segurança.

O legado da RFC 2389 está nessa contenção. O servidor dizia quais extensões declarava conhecer. O cliente escolhia aquilo que compreendia. Depois, identidade, autorização, recursos, respostas e estado final decidiam a transação real. Um repertório orienta a conversa; não escreve o seu desfecho.

Fontes