Zusammenfassung

  • Der klassische FTP-Neustart koppelte eine Sender- mit einer Empfängerposition und konnte dauerhafte Speicherung sowie Transformationszustand abbilden.
  • REST STREAM machte daraus später die Anzahl der Oktette, die beim nächsten Transfer ausgelassen werden. Dieser Offset gehört zu einer Übertragungsdarstellung, nicht zu einer Dateiversion.
  • Das Beispiel in RFC 3659 setzt ausdrücklich eine Prüfung voraus, dass sich die Serverdatei nicht verändert hat. Die Annahme stammt nicht aus REST.

802816 war eine Position, kein Herkunftsnachweis

Ein Download bricht nach 802816 Oktetten ab. Der Client verbindet sich neu, setzt TYPE I, sendet REST 802816, erhält 350 und startet anschließend RETR. Der Server liefert den Rest.

Er hat damit nur bestätigt, einen Wert für den nächsten Transfer gespeichert zu haben. Der lokale Teil könnte zu einer älteren Version gehören; der entfernte Pfad könnte inzwischen ersetzt worden sein. Ein neues Objekt gleicher oder größerer Länge lässt sich am akzeptierten Offset weitergeben, ohne dass FTP den gemischten Inhalt erkennt.

Lokale Marken für heterogene Dateisysteme

RFC 765 beschrieb Fehlerbehebung bereits als Fortsetzung an einem Prüfpunkt. REST übertrug selbst nichts, sondern positionierte den Server für den unmittelbar folgenden unterbrochenen Dienstbefehl.

Ein universeller Plattenoffset hätte nicht zur Aufgabe gepasst. FTP unterschied logische Bytes von acht Bit breiten Transferbytes. TYPE, STRU und MODE bestimmten Zeichendarstellung, Struktur und Rahmen des Datenstroms. Zwei Hosts konnten dieselbe Datei verschieden speichern und übertragen.

RFC 959 behielt Stream, Block und Compressed bei. Die formatierten Block- und Kompressionsmodi konnten besondere Restart-Marken zwischen Datenblöcken tragen. Der Sender legte eine für ihn verständliche Position ab; der Empfänger ordnete sie seinem eigenen Speicherzustand zu. Gemeinsam war die Zuordnung, nicht die Kodierung.

Dauerhaftigkeit und der Zustand zwischen zwei Zeichen

RFC 1123 korrigierte die Beschreibung der Antwort 110. ssss bezeichnet die Senderposition, rrrr die entsprechende Empfängerposition. Beide Zeichenfolgen durften systemspezifisch sein, weil sie später vom jeweiligen Erzeuger gelesen wurden.

Vor der Rückmeldung sollte der Empfänger alle vorherigen Daten auf stabilen Speicher zwingen. Sonst versprach eine Marke Bytes, die derselbe Ausfall noch aus flüchtigem Speicher entfernen konnte.

Auch eine laufende Umwandlung gehörte zum Prüfpunkt. Bei TYPE A kann CR LF im Netz zu einem einzelnen LF auf Platte werden. Fällt eine Marke zwischen CR und LF, muss der Empfänger speichern, dass CR bereits verbraucht wurde. Eine bloße Dateiposition kann diesen Decoderzustand nicht darstellen.

RFC 1123 definierte deshalb 554 für eine nicht anwendbare Position und 555 für eine TYPE- oder STRU-Abweichung. Ein gültiger Markenstring bleibt an die alte Darstellung gebunden.

Aus der Marke wurde ein Zähler

Das frühe Verfahren war sorgfältig, aber aufwendig. RFC 1123 nannte Restart, ABOR und Block mode 1989 hilfreiche, jedoch nicht weit verbreitete Robustheitsfunktionen und nahm REST nicht in die Mindestimplementierung auf. Daraus folgt keine heutige Verbreitungszahl.

Im Stream-Modus wäre eine explizite Marke nicht von Nutzdaten zu unterscheiden. RFC 3659 standardisierte daher REST STREAM: Die Dezimalzahl gibt an, wie viele Oktette der unmittelbar folgende Transfer nicht noch einmal sendet.

Unterstützung wird über FEAT nach RFC 2389 angekündigt. REST STREAM belegt eine Fähigkeit des Servers, aber keine Unveränderlichkeit des angeforderten Pfads.

Der Zähler ist darstellungsabhängig. Dasselbe Textobjekt hat im Beispiel von RFC 3659 unter TYPE I eine SIZE von 1830, unter TYPE A dagegen 1942, weil Zeilenenden verändert werden. Die Zahl liegt im erzeugten Übertragungsstrom und ist nicht zwingend der native Plattenindex.

Beim Fortsetzen eines Uploads benötigt der Client die serverseitig korrekt gespeicherte Länge. SIZE kann sie unter den aktuellen Parametern ausdrücken, liefert aber keinen Hash des vorhandenen Präfixes.

Die Norm benennt ihre Voraussetzung

Vor REST 802816 erklärt RFC 3659, der frühere Transfer habe TYPE I verwendet und die Serverdatei sei seitdem nachweislich unverändert. Gerade diese Prüfung fehlt dem Befehl selbst.

Bei RETR verantwortet der Client die Verbindung des neuen Suffixes mit seinem Teilstück. Bei STOR schreibt der Server in ein vorhandenes Objekt. Das Ergebnis ist undefiniert, wenn nicht der zuvor gescheiterte Transfer vollendet wird, die Marke nicht am Ende der gespeicherten Daten liegt oder das neue Suffix die frühere Länge nicht wieder erreicht. Ein zugelassenes APPE muss nach REST wie STOR an der Marke wirken.

Die folgende Anweisung entscheidet

REST muss unmittelbar vor dem Datenbefehl stehen. Ein Server kann den Wert mit 350 annehmen und erst bei RETR oder STOR feststellen, dass er außerhalb des Bereichs liegt. Scheitert das Senden des Folgebefehls, sollte der Client REST wiederholen, statt alten Serverzustand vorauszusetzen.

Der tatsächliche Prüfpunkt verteilt sich damit auf Teilinhalt, Parameter, Fähigkeit, stabile Speicherung, Marke, Befehlsfolge und externe Versionsprüfung. Wer nur den Offset speichert, bewahrt nicht den vollständigen Wiederanlaufvertrag.

Grenzen der Belege

RFC 765 dokumentiert den Ursprung, RFC 959 die Modi, RFC 1123 die gepaarten Positionen, RFC 2389 die Erkennung und RFC 3659 STREAM sowie SIZE. Sie messen keine heutige Verbreitung und garantieren keine Versionshaltung. FTP-Restart ist weder Authentisierung noch Inhalts-Hash, Snapshot oder Exactly-once-Übertragung.