Leuffen.deBlog

Magazin

Gegenprobe: Ist ein HTTP-GET wirklich nebenwirkungsfrei?

RFC 9110 definiert GET als sichere Methode, schließt aber serverseitige Wirkungen wie Protokollierung nicht aus, solange sie nicht der vom Client verlangte Zweck sind.

Veröffentlicht am
Veröffentlicht von
Redaktion Blog Leuffen.de
Geprüft von
Clara Winter, Inhalt und Struktur, Redaktion und Recherche, Eindeutigkeitsprüfung

Behauptung: Ein HTTP-GET ist sicher und deshalb garantiert nebenwirkungsfrei.

Gegenprobe: RFC 9110 definiert GET tatsächlich als sichere Methode. Sicher bedeutet dort: Der Client fordert mit der festgelegten Semantik im Wesentlichen nur lesenden Zugriff an und erwartet keine Zustandsänderung auf dem Ursprungsserver. Die Definition garantiert nicht, dass eine Implementierung intern überhaupt nichts verändert.

HTTP ist das Protokoll für Anfragen zwischen Webclients und Servern. GET fordert die aktuelle Darstellung einer Ressource an.

Die Behauptung ist in zwei Richtungen falsch: GET kann serverseitige Wirkungen haben, die der Client nicht angefordert hat. Eine vom Client beabsichtigte fachliche Zustandsänderung darf dagegen nicht hinter der Semantik einer sicheren Methode verborgen werden.

Protokollbedeutung und Serverwirkung sind nicht dasselbe

Ein Server kann bei GET einen Zugriffslogeintrag schreiben. Ein Werbesystem kann einen Abruf zählen und einem Abrechnungskonto zuordnen. RFC 9110 nennt solche Wirkungen ausdrücklich, ohne GET dadurch seine Eigenschaft „safe“ zu nehmen. Entscheidend ist: Der Client hat sie nicht als Zweck der Anfrage verlangt.

Damit ist „safe“ eine Aussage über die vereinbarte Bedeutung der Methode, nicht über einen garantiert unveränderten Speicherzustand des gesamten Systems.

Ein zweiter Begriff ist idempotent. Eine Methode ist idempotent, wenn mehrere gleiche Anfragen dieselbe beabsichtigte Wirkung haben wie eine einzige. Sichere Methoden sind nach RFC 9110 auch idempotent. Trotzdem kann der Server jeden Abruf einzeln protokollieren, weil sich auch diese Eigenschaft auf die beabsichtigte Wirkung bezieht.

Warum Löschen per GET gefährlich ist

Browser, Suchmaschinen, Linkprüfer und Cache-Systeme dürfen sichere Methoden automatisch verwenden. Ein Browser kann einen Link vorladen; ein Crawler kann jede gefundene URL besuchen, um einen Index aufzubauen. Genau dafür ist die Unterscheidung zwischen sicheren und unsicheren Methoden gedacht.

Liegt hinter /konto?aktion=loeschen eine Löschfunktion, die schon bei GET ausgeführt wird, kann ein automatischer Abruf eine Geschäftsaktion auslösen, die kein Mensch bestätigt hat. RFC 9110 verlangt deshalb, eine unsichere Aktion zu deaktivieren oder abzulehnen, wenn sie über eine sichere Methode erreicht wird.

Vom Client beabsichtigte fachliche Zustandsänderungen gehören in eine semantisch passende unsichere Methode, etwa POST, PUT oder DELETE. Interne Effekte wie Zugriffsprotokolle ändern daran nichts.

Eine praktische Prüfliste

  1. Ändert ein GET-Endpunkt als eigentlichen Zweck fachlichen Zustand, etwa Bestellung, Freigabe, Abonnement oder Löschstatus?
  2. Kann ein Linkprüfer, Prefetcher oder Suchmaschinen-Crawler den Endpunkt erreichen?
  3. Löst die für GET vorgesehene Behandlung bei HEAD unbeabsichtigt denselben fachlichen Effekt aus?
  4. Ist eine Zustandsänderung nur interner Nebeneffekt — oder der vom Client verlangte Zweck?

Die Gegenprobe fällt klar aus: Die Einstufung als sicher schließt serverseitige Nebenwirkungen nicht aus. Sie verbietet aber, eine fachlich zustandsändernde Geschäftsaktion als Zweck einer GET-Anfrage abzubilden.

Quellen

Quellenstand: 24. September 2026.