Zusammenfassung

  • 340 erlaubte nur die Übertragung; erst 240 oder 441 nach dem vollständigen Artikel entschied den POST.
  • Ein Verbindungsabbruch konnte eine bereits gesendete positive Endantwort vor dem Client verbergen.
  • Eine unveränderte Message-ID hielt den Wiederholungsversuch bei demselben Artikel, ohne sofortige Sichtbarkeit oder Exactly-once zu behaupten.

Die Unsicherheit begann nach dem letzten Byte

Der Client hat Header, Text und Terminator übertragen. Wenn die Verbindung jetzt verschwindet, sieht er keinen Unterschied zwischen zwei Abläufen: Der Server lehnte ab, oder er nahm an und nur die Antwort ging verloren.

Ein neuer Versand kann den ersten Fall beheben und im zweiten einen Doppelgänger erzeugen. Nichtstun kann einen Doppelgänger vermeiden und im ersten Fall den einzigen Beitrag verlieren. Die Wiederholung brauchte deshalb eine Identität, die beide Möglichkeiten überstand.

POST besaß eine Eingangs- und eine Ergebnisantwort

RFC 977 führte 340 als Aufforderung zum Senden und 440 als lokale Ablehnung ein. Nach dem gesamten Artikel folgte 240 für Erfolg oder 441 für Fehlschlag. Das erste Ja war eine geöffnete Eingabe, keine Annahmebescheinigung.

RFC 3977 bewahrte diese Zweiteilung und untersagte das Pipelining von POST. Die Codes 340 und 440 antworten unmittelbar auf den Befehl; die Endcodes kommen erst nach der Punkt-Terminierung.

240 sollte zusagen, dass der Artikel vorbehaltlich unvorhergesehener Serverfehler lokal bereitgestellt oder angemessen weitergeleitet wird, gegebenenfalls nach weiterer Verarbeitung. Unerwünschtes Material sollte mit 441 zurückgewiesen und nicht nach stiller Annahme verworfen werden.

Annahme war nicht die Leseransicht

Der Client darf ohne positive Endantwort keinen Erfolg annehmen. Selbst mit 240 darf er nicht voraussetzen, dass andere Clients den Artikel bereits erhalten können; eine explizite Prüfung wie STAT ist nötig.

Der RFC 5537 ordnet die Rollen: Ein Posting Agent erstellt einen Proto-Artikel, ein Injecting Agent prüft und injiziert ihn, Moderation kann dazwischenliegen, Relaying Agents verteilen ihn und ein Serving Agent stellt ihn Lesern bereit. Diese Grenzen bleiben auch dann sinnvoll, wenn ein Programm mehrere Rollen ausführt.

Ein fehlender Lesetreffer kann daher auf Moderation oder Verzögerung hindeuten. Er beweist nicht, dass der frühere POST verworfen wurde. Gerade die sichtbare Abwesenheit konnte eine voreilige zweite Einspeisung auslösen.

Der erneute Versuch sollte denselben Gegenstand benennen

RFC 3977 behandelt den Abbruch vor Empfang der Antwort ausdrücklich: Eine bejahende Antwort kann gesendet und verloren worden sein. In einer späteren Sitzung sollte der Client den Erfolg vor erneutem Senden prüfen oder sicherstellen, dass der neue Versuch dieselbe Message-ID erhält.

Die zweite Variante wird bevorzugt, weil der Artikel etwa wegen Moderation noch nicht lesbar sein könnte. Im Anhang empfiehlt der RFC, den Inhalt des Message-ID-Feldes bei jedem Versuch identisch zu halten. Der Server sollte solche POSTs als denselben Artikel erkennen.

Diese ID belegt weder den ersten Erfolg noch die Urheberschaft. Sie verhindert, dass die Wiederherstellung einen zweiten Gegenstand behauptet. Eine neue Message-ID würde selbst bei gleichem Text einen getrennten Moderations-, Verteilungs- und Aufbewahrungsweg eröffnen.

Die History begrenzte Duplikate, nicht alle Fehler

RFC 5536 definiert Message-ID als eindeutige Artikelkennung und betont die schnelle Vergleichbarkeit. Nach RFC 5537 kann ein Server im Flood-Fill-Netz denselben Artikel von mehreren Nachbarn angeboten bekommen. Relaying und Serving Agents führen deshalb eine History bereits gesehener IDs.

Die stabile ID macht zwei Übertragungsversuche als einen Artikel erkennbar. Sie bietet dennoch kein Exactly-once: History-Einträge werden begrenzt aufbewahrt, lokale Regeln unterscheiden sich und ein Ausfall kann um die Persistenzgrenze liegen. Ihr Wert ist die Reconciliation. Empfang des Körpers, Endantwort, Injektion, Moderation, Relay und Lesbarkeit lassen sich für eine Identität getrennt prüfen.

Die IANA-Registrierung der NNTP-Parameter nennt POST mit RFC 3977. Sie beweist weder eine aktuelle Posting-Berechtigung noch die History-Dauer eines Servers.

NNTP konnte die verlorene Antwort nicht zurückholen. Es konnte aber verhindern, dass ein unsicherer Neuversuch einen neuen Namen und damit ein zweites öffentliches Leben bekam. Die Identität hielt den Fehler begrenzt.

Sources