Resumo

  • O mecanismo histórico colocava marcadores nos modos em bloco ou comprimido e unia a posição do emissor ao estado persistido do receptor em uma resposta 110 MARK.
  • Os valores eram próprios de cada sistema e podiam incluir estado de transformação. Um receptor que convertia CRLF em LF precisava lembrar até um CR já consumido.
  • O RFC 3659 definiu REST STREAM como uma contagem de octetos para a transferência imediatamente seguinte, mas o offset não identificava a versão nem comprovava o arquivo final.

Duas linhas de trabalho, um ponto recuperável

FTP mantém comandos e respostas em uma conexão de controle e carrega o arquivo em outra conexão de dados. Por isso o receptor podia emitir um checkpoint sem interromper a carga útil. A resposta passava por um caminho enquanto o arquivo avançava pelo outro.

O RFC 1123 corrige a definição de 110 MARK ssss = rrrr. ssss era uma cadeia vista no fluxo e codificava uma posição no sistema de arquivos do emissor. rrrr codificava a posição correspondente no sistema receptor. Cada sistema gerava e mais tarde interpretava seu próprio valor.

O sinal de igualdade registrava correspondência, não equivalência numérica. O coordenador não precisava converter um marcador no outro. Guardava o par e devolvia a cada ponta somente o valor que aquela ponta sabia usar.

O emissor também não podia aguardar uma resposta 110 antes de seguir. As respostas não eram necessariamente síncronas. O último checkpoint seguro podia ficar atrás do maior contador visto na tela. Progresso dizia quanto trabalho ocorreu; recuperabilidade dizia qual trabalho continuaria fazendo sentido depois de uma falha.

O enquadramento criava espaço para o marcador

O RFC 959 trata tipo de representação, estrutura de arquivo e modo de transmissão como parâmetros diferentes. No modo STREAM, o encerramento da conexão de dados normalmente indica EOF. O próprio texto observa que esse encerramento não distingue, sozinho, fim legítimo de ruptura prematura.

No modo em bloco, cada unidade tinha um cabeçalho de três octetos: oito bits de descritor e dezesseis de tamanho. O valor 16 no descritor anunciava um bloco de restart marker. Seu conteúdo era uma cadeia imprimível sem espaço, embutida na representação FTP e separada do arquivo do usuário.

Não era um número de sequência TCP nem um caractere reservado no documento. Era um marco do protocolo de aplicação. Os modos em bloco e comprimido também conseguiam declarar EOF sem fechar a conexão, razão pela qual suportavam o desenho antigo de retomada.

Um registro de pacotes não conhecia a posição que o gerador podia reconstruir nem a posição que o armazenador conseguia reabrir. A prova de retomada pertencia aos processos de transferência.

A durabilidade vinha antes do token

Ao receber um marcador, o RFC 1123 recomenda forçar todos os dados anteriores a armazenamento estável e só então produzir rrrr. Assim, o receptor não prometia uma fronteira ainda presa a buffers voláteis. O token era sustentado pela capacidade local de voltar àquele estado.

Estável não significava eterno, replicado ou imune a todo desastre. O padrão não definia uma política de armazenamento. Ele exigia que o sistema não emitisse uma posição que sua própria recuperação não pudesse honrar.

O User-FTP deveria persistir os pares em um arquivo de controle: criá-lo vazio no início, anexar checkpoints completos e apagá-lo depois da conclusão. Se o processo caísse, o último par íntegro seria o candidato, não o maior valor de uma interface.

Apagar o arquivo após o sucesso também protegia a próxima operação. Um checkpoint sem vínculo com origem, direção, parâmetros e validade temporal pode virar uma instrução antiga aplicada a um objeto novo.

Uma conversão de linha cabia dentro da posição

O exemplo mais claro do RFC 1123 usa TYPE ASCII. A rede carrega CRLF; o destino pode armazenar apenas LF. Se o marcador aparecer entre CR e LF, o receptor já consumiu CR, mas ainda não concluiu a transformação da quebra de linha.

Seu rrrr precisa guardar essa memória, além da posição física. Recomeçar apenas em um deslocamento no disco pode repetir ou omitir parte da sequência. A posição recuperável inclui o estado do conversor.

FTP foi desenhado para máquinas com códigos de caracteres, palavras e bytes lógicos diferentes. Uma representação comum durante o transporte não apagava as diferenças de armazenamento. Marcadores opacos permitiam precisão sem criar um sistema universal de coordenadas que falharia justamente nos casos heterogêneos.

A opacidade delimitava autoridade. O remetente entendia seu marcador; o receptor entendia o dele; o protocolo preservava o encontro entre ambos.

A direção alterava a posse dos valores

Num envio do usuário para o servidor, o usuário inseria ssss. O servidor gravava o prefixo, criava rrrr e devolvia o par. Para retomar, o usuário restaurava seu lado com ssss e enviava REST rrrr ao servidor.

Num download, o servidor inseria o marcador. O cliente persistia a cópia parcial e guardava seu ponto local. Depois restaurava esse estado e devolvia ao servidor o marcador originalmente criado pelo servidor.

FTP ainda previa transferência entre dois servidores sob comando de um processo usuário. O coordenador mantinha dois estados remotos que não precisava interpretar. Mandava cada token de volta a seu autor.

Essa custódia mínima funcionava somente se os pares não fossem misturados entre arquivos, sessões ou sentidos. A cadeia de caracteres não carregava, sozinha, contexto suficiente para impedir reutilização indevida.

REST armazenava intenção, não bytes

Uma resposta 350 a REST indicava que o servidor guardara um parâmetro e aguardava um comando de transferência. Não significava conclusão, integridade ou entrega de novos dados.

No modelo do RFC 959, vinham depois RETR, STOR ou, em certas condições, APPE. O RFC 1123 separou 554, para posição que não podia ser aplicada, e 555, para incompatibilidade de TYPE ou STRU com o arquivo existente. Coordenada e representação precisavam concordar.

O intervalo entre os dois comandos criava estado pendente. Se REST fosse aceito e a ação seguinte não chegasse, uma operação posterior poderia herdar intenção velha. A extensão de STREAM passou a exigir adjacência explícita.

REST STREAM escolheu o caso dos octetos

O RFC 3659 definiu retomada em STREAM sem inserir marcadores na conexão de dados. O argumento tornou-se um inteiro decimal: quantos octetos a transferência imediatamente posterior não deve enviar. REST 0 volta ao arquivo inteiro.

O exemplo seleciona TYPE I, verifica que o arquivo do servidor não mudou, envia REST 802816, recebe 350 e emite RETR. Para uma imagem binária, o número fornece uma coordenada simples e útil.

Mas ele não contém estado de conversão, identidade de versão ou prova de que o cliente ainda possui o prefixo certo. A simplificação descreve omissão no próximo fluxo, não a história completa do objeto.

REST deve ser o último comando antes de RETR ou STOR. Se o comando de dados não puder ser enviado, o cliente deve repetir REST; se não quiser retomar, deve usar REST 0. Um valor numericamente válido pode ser rejeitado só no comando seguinte, quando o servidor conhece arquivo, operação e intervalo.

Retomar STOR dava poder sobre um parcial remoto

Em RETR, o cliente decide como unir o sufixo. Em STOR, o servidor escreve no objeto parcial. Um offset errado pode combinar versões ou modificar bytes sob um nome já existente.

O RFC 3659 destina esse uso apenas a completar um envio que falhou. O resultado é indefinido se o marcador não estiver no final dos dados atuais do servidor, ou se a continuação não estender o destino ao menos até o tamanho anterior. APPE, se aceito, deve agir como STOR na posição escolhida em vez de simplesmente anexar.

Esses limites impedem que REST vire edição remota arbitrária, mas não tornam a operação transacional. Outra falha deixa outro parcial. A política do servidor precisa decidir nome, visibilidade, autorização, substituição e limpeza.

Saber aplicar uma posição não é o mesmo que ter permissão para alterar o objeto.

O mesmo offset podia apontar para outra versão

O RFC 3659 recomenda obter a modificação do arquivo antes do primeiro RETR e comparar antes da retomada. Para STOR, o cliente pode comparar a origem atual com o parcial remoto. Informações de MLST podem oferecer indicação mais forte.

O texto não transforma horário em identidade. Relógios podem ter diferença; a marca pode mudar sem mudança final de conteúdo; o conteúdo pode mudar e voltar. Ela serve como motivo para invalidar um checkpoint, não como prova criptográfica.

SIZE também depende do TYPE e descreve tamanho de transferência. Arquivos diferentes podem ter o mesmo tamanho. Chegar à extensão esperada não mostra que prefixo e sufixo pertencem à mesma geração.

Quando integridade importa, a retomada precisa terminar com verificação do arquivo completo. Uma sequência 350, 150 e 226 comprova o diálogo previsto, não igualdade dos bytes montados.

FEAT anunciava uma forma, não o estado do objeto

Servidores que suportam o comportamento STREAM do RFC 3659 anunciam REST STREAM em FEAT. O cliente consegue distinguir o offset decimal de suporte restrito aos modos enquadrados.

O registro IANA de comandos e extensões FTP mantém REST na base e REST+ para STREAM. O registro preserva vocabulário e classificação de conformidade; não mede implantação nem certifica uma execução.

A linha FEAT responde se o servidor declara compreender a sintaxe. Não responde se o arquivo permaneceu igual, se o parcial é autêntico, se a conta pode escrever ou se o resultado está correto.

A retomada funcionava enquanto o checkpoint permanecia menor que o arquivo

O desenho antigo preservava mais significado local e exigia modos enquadrados, respostas assíncronas e um arquivo lateral. O desenho STREAM escolheu uma coordenada comum e deslocou para o cliente o dever de validar versão e resultado.

Em ambos, o checkpoint só autorizava uma tentativa de continuação. Não autenticava o fornecedor, não explicava o conteúdo e não liberava o arquivo para execução. O estado parcial precisava poder expirar quando o objeto ou seus parâmetros mudassem.

Economizar retransmissão é manter trabalho anterior sob condição. Sem a evidência dessa condição, a economia pode produzir um arquivo completo na aparência e impossível de defender.

Fontes e limites da evidência

As fontes fechadas demonstram a especificação e sua evolução. Elas não medem suporte atual, uso, taxa de sucesso ou integridade de um servidor real. Uma entrada IANA ou anúncio FEAT não torna uma retomada específica segura.