Postel's Law, auch Robustness Principle, ist Jon Postels Interoperabilitätsregel aus RFC 760/761 (1980) für TCP/IP: „Be conservative in what you send, be liberal in what you accept.“ Systeme senden nur spezifikationskonformen Output, tolerieren beim Input aber kleine Abweichungen und ignorierbare Felder; das hilft langlebigen Protokollen, APIs und Schemas bei der Weiterentwicklung. Kritiker, darunter RFC 9413, warnen, dass pauschale Toleranz Mehrdeutigkeit und Sicherheitslücken erzeugt, und bevorzugen striktes Parsing mit expliziter Versionierung.

Postel’s Law

Details
Vollständiger Name

Postel’s Law / Robustness Principle (Robustheitsprinzip)

Auch bekannt als

„Be conservative in what you send, be liberal in what you accept"

Kernkonzepte:

Das Prinzip

Strikt konformen Output senden; Input tolerant annehmen und alles Vertretbare verarbeiten — um die Interoperabilität unabhängig gebauter Systeme zu maximieren

Konservativer Output

Nur wohlgeformte, spezifikationskonforme Nachrichten senden, damit Gegenstellen nie deine Nachlässigkeit ausgleichen müssen

Liberaler Input

Kleine Abweichungen und unbekannt-aber-ignorierbare Felder tolerieren statt sonst nutzbare Nachrichten abzulehnen — stützt Vorwärts-/Rückwärtskompatibilität

Wo es glänzt

Langlebige Netzprotokolle, öffentliche APIs, Dateiformate und Event-Schemas, die sich weiterentwickeln müssen, während alte und neue Teilnehmer koexistieren

Die moderne Kritik

Übermäßige Toleranz häuft undefiniertes Verhalten und Sicherheitsrisiken an (mehrdeutiges Parsing, Smuggling); aktuelle Empfehlung bevorzugt Striktheit plus explizite Versionierung. Mit dokumentierter Toleranzgrenze anwenden, nicht pauschal nachsichtig

Key Proponents

Jon Postel (RFC 760/761, 1980, im Kontext von TCP/IP)

Verwendung:

  • Entwurf von Protokoll-, API- oder Event-Schema-Contracts, die sich entwickeln müssen

  • Entscheidung, wie strikt ein Parser/Validator Input ablehnen soll

  • Nachdenken über Vorwärts-/Rückwärtskompatibilität und Graceful Degradation

Nicht verwenden:

  • Sicherheitskritisches Parsing, wo Mehrdeutigkeit gefährlich ist — lieber strikte Validierung

  • Interne Schnittstellen unter Kontrolle eines Teams, wo Striktheit Bugs früher fängt

Verwandte Anker:

Kritik:

  • Eric Allman, "The Robustness Principle Reconsidered" (ACM Queue, 2011) — Jahrzehnte liberaler Annahme züchteten De-facto-Protokoll-Forks und Sicherheitslücken; Toleranz, die als Übergang gedacht war, wurde permanent

  • RFC 9413, "Maintaining Robust Protocols" (Thomson & Schinazi, IETF, 2023) — offizielle IETF-Leitlinie, dass pauschale Nachsicht Protokoll-Ökosystemen langfristig schadet; mehrdeutige Toleranz ermöglicht Interoperabilitätsfehler und Angriffe wie Request Smuggling

  • Im Diskurs benannte Alternative: aktive Protokollpflege mit striktem Parsing und expliziter Versionierung ("fail fast") statt stillschweigender Annahme fehlerhaften Inputs — siehe Semantic Versioning