Zusammenfassung

  • RFC 2068 nahm 402 Payment Required im Januar 1997 in HTTP/1.1 auf und gab dem Code genau eine Regel: „für künftige Verwendung reserviert“.
  • RFC 2616, RFC 7231 und RFC 9110 führten diese Reservierung fort. Für 402 liefert HTTP bis heute weder einen gemeinsamen Preis noch eine Zahlungsaufforderung oder Abwicklungsregel.

Das Schild kam vor der Kasse

RFC 1945 erklärte Statuscodes als maschinenlesbare Ergebnisse und führte die damals anerkannten HTTP/1.0-Werte auf. In der Liste der Clientfehler folgte auf 401 Unauthorized direkt 403 Forbidden; 402 fehlte. Erweiterungscodes waren zulässig, die Zahl konnte also als Erweiterung auftauchen. Eine eigene Bedeutung erhielt sie im veröffentlichten Katalog nicht. RFC 1945 §§6.1.1–6.1.2

Die HTTP/1.1-Spezifikation RFC 2068 vom Januar 1997 nahm 402 in die Statuscode-Grammatik auf und widmete ihm Abschnitt 10.4.3. Die ganze Regel passte in einen Satz: „This code is reserved for future use.“ Das Etikett kündigte eine Zahlungsschranke an. Der normative Text erklärte keine Abwicklung dahinter. RFC 2068 §§6.1.2, 10.4.3

Ein Statuscode ordnet eine Antwort ein. Die Definition von 402 nennt weder Betrag noch Währung, Empfänger, Zahlungsnachweis, Bestätigung, Abrechnung oder Streitverfahren. Ein Server kann seine eigenen Bedingungen im Antworttext erläutern. HTTP macht sie dadurch nicht zwischen verschiedenen Clients und Diensten nutzbar.

401 bekam eine Aufforderung. 402 blieb im Wartezimmer.

Der benachbarte Code 401 zeigt, wie ein gemeinsamer Ablauf spezifiziert werden kann. RFC 9110 verlangt bei einer 401-Antwort ein WWW-Authenticate-Feld mit mindestens einer passenden Herausforderung. Ein Client kann das Verfahren lesen und entscheiden, welche Zugangsdaten nötig sind. Abschnitt 15.5.3 gibt 402 keine entsprechende Handlung mit: Er wiederholt die Reservierung und endet dort. RFC 9110 §§15.5.2–15.5.3

Die Anwendungsentwickler müssen den Rest bauen. Wer eine Ressource hinter eine Zahlung stellt, braucht Regeln für den geschuldeten Betrag, den Zahlungsnachweis, den Empfänger und den Fall, dass Nachweis oder Abrechnung scheitern. HTTP setzt das Ablehnungsschild. Kasse, Beleg und Fehlerpfad bleiben Arbeit des Dienstes.

Die Zukunft bekam mehrere Verlängerungen

RFC 2616 wiederholte den Satz im Juni 1999 in Abschnitt 10.4.3. RFC 7231 tat es 2014, RFC 9110 erneut 2022. Die Abschnittsnummer wechselte; die Reservierung blieb. Jede Überarbeitung aktualisierte HTTPs Semantik und nahm den unbezahlten Platz in die nächste Ausgabe mit. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

Die RFCs nennen kein Zahlungssystem, das ihre Autoren erwartet hätten. Ein zeitgenössischer Entwurf mit einem konkreten Namen würde die historische Erklärung ändern. Die veröffentlichten Standards belegen den Namen und die Reservierung, nicht den Ursprung der Lücke.

Im für diesen Artikel geprüften, zuletzt am 15. September 2025 aktualisierten IANA-Register steht 402 weiterhin als „Payment Required“ und verweist auf RFC 9110, Abschnitt 15.5.3. IANA-Register der HTTP-Statuscodes

Die Integrationsrechnung landet bei den Entwicklern

Hier wird die Ökonomie einer Entwickler-Schnittstelle sichtbar. Ein gemeinsames Protokoll kann Teams davon entlasten, dieselben Abläufe in getrennten Handbüchern neu auszuhandeln. HTTP 402 erledigt diese Arbeit nicht. Client und Server müssen sich auf Anwendungsebene über Preis, Nachweis, Zugangsdaten, Wiederholung und Zahlungsabschluss einigen. Die Entwickler tragen Integration und Wartung; der Dienst behält seine Bedingungen in der Hand.

402 ist damit eine Bezeichnung für einen Zustand und keine Zahlungsschnittstelle. Der Code sagt dem Client, dass der Server den Zugang an eine Zahlung knüpft. Er liefert keinen gemeinsamen Weg, diese Bedingung zu erfüllen. Die Kasse bleibt eine lokale Regel mit standardisierter Nummer.

Quellen