Zusammenfassung

  • STOU wurde als eigener optionaler Befehl geschaffen, weil die Autoren den etablierten STOR-Code nicht für eine neue Namensregel wieder öffnen wollten.
  • Der getrennte Name schützte Kompatibilität an einer Stelle, erzeugte aber neue Pflichten für Unterstützung, Antwortgrammatik, Registrierung und das Zusammenspiel mit späteren Erweiterungen.

Der alte Befehl sollte unangetastet bleiben

Im Juli 1985 fragte der RFC 949, wie FTP eine Datei speichern könne, deren endgültigen Namen der Server bestimmt. Zur Wahl standen eine Änderung von STOR, ein Steuerargument und eine Sonderbedeutung für STOR ohne Argument. Alle drei Varianten hätten den vorhandenen Befehlscode erneut geöffnet.

Die Autoren gingen von einer Implementierung aus, die Befehlsnamen über eine Tabelle oder einen ähnlichen Dispatch trennt. Einen neuen Eintrag hinzuzufügen erschien leichter, als die Semantik des etablierten STOR zu verändern. So entstand STOU: Store Unique. Der Name war nicht nur eine Abkürzung, sondern eine Kompatibilitätsgrenze um vorhandenen Code.

Die Funktion sollte STOR gleichen, außer dass der Server im aktuellen Verzeichnis einen dort freien Dateinamen erzeugt. Als Anwendungsfälle dienten Pool-Verzeichnisse für Drucker-, Fax- und Lochkartenwarteschlangen. Der Server überblickte den Namensraum, während der Client lediglich Inhalt anlieferte.

RFC 949 entschied außerdem, dass der erzeugte Name an den Client zurückgegeben werden müsse. Diese Mitteilung sollte nicht optional sein. Zugriffssteuerung, Authentifizierung und Abrechnung blieben dennoch eigenständig. Der neue Befehl erweiterte die Speichermethode, nicht die Berechtigung.

Ein eigener Name macht Unterstützung sichtbar — aber nicht selbstverständlich

Der RFC 959 nahm STOU drei Monate später unter sieben neuen optionalen FTP-Befehlen auf. Seine Syntax lautet STOU <CRLF>. Anders als STOR trägt er keinen Pfadparameter. Der zuvor gewählte aktuelle Verzeichniskontext bleibt relevant; innerhalb dieses Bereichs vergibt der Server den kollisionsfreien Namen.

Die Kennzeichnung als optional ist ein wichtiger Teil der Erweiterungsgeschichte. STOU gehört zur Basisbeschreibung von RFC 959, aber nicht jede Implementierung muss den Befehl unterstützen. Ein Client kann daher aus der Existenz des Standards nicht auf die Fähigkeit eines konkreten Servers schließen. Die getrennte Syntax vermeidet eine stille Bedeutungsänderung von STOR, verlangt aber eine sichtbare Entscheidung über den neuen Eintrag.

Diese Sichtbarkeit hat zwei Seiten. Ein unbekannter eigener Befehl kann ausdrücklich zurückgewiesen werden, ohne dass STOR dadurch seine alte Bedeutung verliert. Zugleich muss der Client den Unterschied zwischen „Server versteht STOU nicht“ und „Server versteht ihn, lehnt aber diesen Vorgang aus einem anderen Grund ab“ aus den tatsächlichen Antworten bewahren. Wer jede negative Antwort in einen automatischen STOR-Fallback verwandelt, führt die Namensentscheidung wieder in den Pfad ein, den die neue Operation gerade vermeiden sollte.

Die Eindeutigkeit ist ebenfalls begrenzt. Sie gilt gegenüber den Namen im aktuellen Verzeichnis. Derselbe String kann an anderer Stelle vorkommen, später umbenannt werden oder verschwinden. Der Befehl vergibt weder eine Inhaltskennung noch eine weltweit dauerhaft gültige Kennung für die gespeicherte Datei.

Das Dateisystemproblem war älter als die Erweiterung

Der RFC 172 definierte 1971 Dateien über Pfade innerhalb eines Systems. FTP vereinheitlichte Operationen, nicht die Namenskonventionen der beteiligten Hosts. Ein Client musste die fremde Pfadsprache beherrschen. Bei normalem Speichern konnte ein angegebener Pfad neu entstehen oder vorhandenen Inhalt ersetzen.

Der selektive Zugriff blieb beim residenten Dateisystem. FTP transportierte Kennungen und Passwörter, ersetzte aber nicht dessen Schutzmodell. STOU entfernte später den Pfadparameter aus einer einzelnen Anforderung; es standardisierte weder alle Dateisystemnamen noch einen neuen Sicherheitsmechanismus.

Der RFC 505 zeigte 1973 einen Zwischenschritt. Ein vorgeschlagenes Pool-Verzeichnis nahm Dateien für andere Benutzer entgegen, benachrichtigte die Empfänger und ließ sie später kopieren. Der Vorschlag POOL id name erlaubte einen Wunschnamen, den der Server bei Kollision mit Präfix oder Suffix anpassen sollte.

Damit konnte die lokale Zeichenkette schon vor STOU vom Clientwunsch abweichen. Zugleich blieben Empfänger, Pool-Ort, Namensanpassung und Benachrichtigung getrennt. Das ist eine Entwurfslinie, kein Beleg für eine allgemein eingesetzte POOL-Implementierung oder ihre direkte Standardisierung.

Die neue Kommandozeile erbte eine fehlerhafte Antwort

Die Abgrenzung durch den Befehlsnamen reichte nicht aus. RFC 959 verlangte den erzeugten Namen in einer „250 Transfer Started“-Antwort. Im selben Dokument bedeutet 250, dass die verlangte Dateiaktion abgeschlossen ist. Die Antworttabelle nennt dagegen 125 oder 150 vor und 226 oder 250 nach dem Datentransfer.

Der RFC 1123 korrigierte die Spezifikation 1989. Der tatsächliche Pfad muss vor dem Transfer in 125 FILE: pppp oder 150 FILE: pppp erscheinen. Der feste Marker macht den Pflichtwert in einem ansonsten serverabhängigen Antworttext maschinenlesbar. Die spätere Abschluss- oder Fehlerantwort bleibt eine eigene Phase.

Damit wird auch die Fehlerklasse des Befehls präziser beobachtbar. Ein Client kann den Namen korrekt erhalten und später dennoch 425, 426, 451, 551 oder 552 als verschiedene negative Ergebnisse sehen. Die frühe Pfadmeldung darf diese Unterschiede nicht überdecken; umgekehrt lässt ein finaler Erfolg den vorläufigen Pfad nicht aus freiem Text neu entstehen, falls der Parser ihn zuvor verloren hat.

Auch dieser Beleg ist eng. „Wird geschrieben“ bedeutet nicht „vollständig geschrieben“, dauerhaft gespeichert oder künftig sichtbar. Zudem müssen Clients entfernte Pfade als beliebige Zeichenketten behandeln. Eine lokale Normalisierung kann den vom Server vergebenen Wert unbrauchbar machen.

Der Vorfall zeigt eine zweite Kompatibilitätsform. Ein neuer Befehl konnte bestehenden STOR-Code schonen und dennoch einen Standardfehler mitbringen, den Serverausgaben und Clientparser später korrigieren mussten. Erweiterungsisolierung schützt nicht vor Irrtümern innerhalb der Erweiterung.

Spätere Funktionen passen nicht automatisch zu der neuen Semantik

Der RFC 3659 erweitert REST für die Wiederaufnahme im Stream-Modus. Auf einen Marker sollte normalerweise RETR oder STOR folgen. Ein Server darf APPE oder STOU akzeptieren, aber das wird nicht empfohlen; STOU nach REST ist semantisch undefiniert.

Wiederaufnahme setzt eine bekannte Zieldatei und eine gemeinsame Position darin voraus. STOU fordert einen neuen Pfad. Die Kombination zweier einzeln verständlicher Funktionen erzeugt daher keinen verlässlichen Gesamtvertrag. Der RFC verbietet ihre Annahme nicht absolut, sondern verweigert eine allgemeine Bedeutung.

Dasselbe Dokument definiert Unique= für maschinenlesbare Listen. Der opake, groß-/kleinschreibungssensitive Token zeigt, ob zwei Pfade dieselbe gespeicherte Datei bezeichnen; die Zuordnung muss wenigstens während der Kontrollverbindung stabil bleiben. Er ist nicht der von STOU zurückgegebene Pfad. Eine Pfadkollision zu vermeiden und zwei Pfade derselben Datei zuzuordnen bleiben getrennte Fragestellungen.

Interne Dateisystemkennungen, die Schutzmechanismen umgehen könnten, eignen sich laut RFC nicht als öffentliche Unique=-Werte. Auch eine Erweiterung für bessere Beobachtbarkeit darf keine neue Zugriffsabkürzung schaffen.

Das Register schützt den Kommandonamensraum

Mit dem RFC 5797 erhielt FTP 2010 ein Register für Befehle und Erweiterungen. Sein Hauptzweck ist, widersprüchliche Verwendungen derselben Namen zu vermeiden. Der Eintrag soll nicht beweisen, dass eine Erweiterung erfolgreich, allgegenwärtig oder von einem bestimmten Produkt unterstützt ist.

Im aktuellen IANA-Register steht STOU als optionaler Basisbefehl mit RFC 959 und RFC 1123 als Referenzen. base ist dabei ein unveränderlicher Pseudo-FEAT-Code. Er ist kein Schlüsselwort, das ein Server in seiner FEAT-Antwort zurückgeben soll. Wer dort nach base sucht, verwechselt die interne Ordnung des Registers mit der Laufzeitanzeige einer Fähigkeit.

Das Register konserviert auch historische und optionale Bezeichnungen, um Namenskonflikte zu vermeiden. Registrierung ist damit ein Mechanismus gegen spätere Kollisionen im Erweiterungsraum. Sie ist weder eine Einsatzstatistik noch ein Ersatz für die Beobachtung tatsächlicher Antworten.

Gerade die Aufbewahrung älterer oder historischer Namen zeigt den Unterschied zwischen Verzeichnis und Ausführung. Ein Eintrag kann fortbestehen, damit eine neue Spezifikation denselben Namen nicht anders belegt, obwohl moderne Unterstützung daraus nicht folgt. Für optionale Basisbefehle wie STOU gilt entsprechend: Der Namensraum ist koordiniert, die konkrete Implementierungsentscheidung bleibt offen.

Der RFC 2577 setzt schließlich die Sicherheitsgrenze. Standard-FTP sendet Passwörter, Steuerinformationen und Daten unverschlüsselt; Risiken von Diebstahl oder Austausch der Datenverbindung bleiben bestehen. Ein sauber registrierter und korrekt beantworteter STOU-Befehl authentifiziert den Inhalt nicht, verschlüsselt ihn nicht und garantiert keine dauerhafte Verwahrung.

Die Geschichte der Erweiterung endet daher nicht beim freien Dateinamen. Ein neuer Befehl begrenzte die Änderung an STOR; eine spätere Korrektur begrenzte die Antwortgrammatik; ein Register begrenzte Namenskonflikte zwischen Erweiterungen. Jede Schicht löste eine andere Kompatibilitätsfrage und ließ die übrigen sichtbar.