php://input verstehen und richtig nutzen: Rohdaten in PHP sauber lesen

Wenn ich in PHP JSON-APIs, Webhooks oder andere POST-Daten verarbeite, ist php://input fast immer Teil der Lösung. Es gibt dir den rohen Request-Body direkt als Stream. Kein Umweg, kein unnötiges Mapping, kein Rätselraten.

Das Problem: Viele nutzen php://input falsch, lesen es mehrfach oder greifen zur falschen Lösung, obwohl $_POST reichen würde. Ich halte es einfach: Wenn du die Rohdaten brauchst, nimm php://input. Wenn nicht, lass es.

Was ist php://input?

php://input ist ein Read-only-Stream in PHP. Er enthält den ungespeicherten Rohinhalt des HTTP-Requests. Das ist besonders wichtig, wenn der Client nicht klassisches HTML-Form-POST sendet, sondern zum Beispiel:

• JSON per API
• XML für Integrationen
• Webhook-Payloads
• generische Raw-Body-Requests

Ich nutze php://input, wenn ich genau das sehen will, was wirklich im Request steckt. Nicht das, was PHP daraus schon interpretiert hat.

php://input vs. $_POST: der Unterschied

Das ist der wichtigste Punkt. $_POST und php://input lösen unterschiedliche Probleme.

• $_POST ist für klassisch codierte Formulardaten da.
• php://input gibt den Roh-Request-Body zurück.

Wenn du ein Formular mit application/x-www-form-urlencoded oder multipart/form-data sendest, ist $_POST oft die bequemere Wahl. Wenn du aber JSON bekommst, ist $_POST meistens leer. Genau dann kommt php://input ins Spiel.

Merksatz: Formulardaten über $_POST, Rohdaten über php://input.

php://input für JSON in PHP

Der häufigste Use Case ist JSON. So lese ich den Body:

$rawBody = file_get_contents('php://input');
$data = json_decode($rawBody, true);

if (json_last_error() !== JSON_ERROR_NONE) {
    http_response_code(400);
    echo 'Invalid JSON';
    exit;
}

Das ist simpel, aber effektiv. Der wichtige Teil ist nicht der Code selbst, sondern die Reihenfolge:

1. Rohdaten lesen
2. JSON dekodieren
3. Fehler prüfen

Wenn ich das sauber mache, spare ich mir später viel Debugging.

Wann ich php://input verwende

Ich setze php://input ein, wenn ich den Request nicht in eine PHP-Formularstruktur pressen will. Typische Fälle:

• REST APIs
• Webhooks von Stripe, GitHub oder anderen Diensten
• Mobile App Requests
• Custom Clients, die eigene Payloads senden

Besonders bei Webhooks ist das wichtig, weil ich die exakte Nutzlast brauche, um Signaturen zu prüfen oder Events korrekt zu verarbeiten.

Wichtige Regeln für php://input

Hier passieren die meisten Fehler. Ich halte mich an diese Regeln:

• Nur einmal sauber lesen und den Inhalt dann speichern.
• Nicht blind vertrauen und immer validieren.
• Content-Type prüfen, bevor ich parse.
• Fehler beim Decoding konsequent abfangen.
• Keine Logik auf unsicheren Rohdaten aufbauen.

Der Stream ist nicht magisch. Er gibt dir Daten. Die Verantwortung bleibt bei dir.

Kann man php://input mehrfach lesen?

Nein, in der Praxis solltest du davon ausgehen, dass du php://input einmal lesen und dann in einer Variable halten musst. Wenn du später nochmal darauf zugreifen willst, nimm die gespeicherte Variable.

$rawBody = file_get_contents('php://input');

// später wiederverwenden
$secondUse = $rawBody;

Genau hier sparen viele Zeit, indem sie den Body direkt am Anfang einer Request-Verarbeitung sichern.

php://input und HTTP-Methoden

php://input ist nicht auf POST beschränkt. Ich nutze es auch bei:

• PUT
• PATCH
• DELETE

Das ist wichtig, weil moderne APIs nicht nur POST verwenden. Wenn du also eine saubere API baust, solltest du deinen Code nicht auf eine einzige Methode begrenzen.

Typische Fehler mit php://input

Ich sehe immer wieder dieselben Probleme. Hier sind die häufigsten:

• Falscher Content-Type wird angenommen.
• JSON wird nicht validiert.
• Rohdaten werden direkt geloggt, obwohl sensible Inhalte drin sind.
• Mehrfaches Lesen erzeugt leere Ergebnisse.
• $_POST wird erwartet, obwohl der Client JSON sendet.

Mein Ansatz: erst verstehen, was ankommt, dann verarbeiten. Nicht umgekehrt.

Best Practices für php://input

Wenn ich php://input verwende, arbeite ich nach ein paar klaren Regeln:

• Content-Type prüfen: Nur das parsen, was ich erwarte.
• Payload klein halten: Große Bodies bewusst behandeln.
• Fehler sauber beantworten: Mit passenden HTTP-Statuscodes.
• Validierung vor Business-Logik: Erst Struktur, dann Inhalt.
• Sicherheitsdenken: Nie auf untrusted input verlassen.

Wenn du mehr zu Request Bodies in PHP lesen willst, sind diese offiziellen Ressourcen nützlich:

• PHP Manual: php:// wrapper
• PHP Manual: file_get_contents()
• PHP Manual: json_decode()

Mein Minimalbeispiel für php://input

So sieht ein schlanker Start für eine API in PHP aus:

$rawBody = file_get_contents('php://input');
$contentType = $_SERVER['CONTENT_TYPE'] ?? '';

if (strpos($contentType, 'application/json') === false) {
    http_response_code(415);
    echo 'Unsupported Media Type';
    exit;
}

$data = json_decode($rawBody, true);

if (!is_array($data)) {
    http_response_code(400);
    echo 'Invalid payload';
    exit;
}

// Weiterverarbeitung hier

Das ist kein overengineered Framework-Pattern. Das ist sauberer Basiskode. Genau so will ich es haben.

Fazit zu php://input

php://input ist die richtige Wahl, wenn du in PHP Rohdaten direkt aus dem Request lesen willst. Besonders für JSON, APIs und Webhooks ist es fast unverzichtbar. Wenn du den Unterschied zu $_POST verstehst, sparst du dir Fehler, leere Variablen und unnötige Frustration.

Mein Rat: Verwende php://input bewusst, lese den Body einmal, prüfe den Content-Type und valide alles, bevor du es weiterverarbeitest. So baust du robuste PHP-Endpoints, die im Alltag wirklich funktionieren. Genau dafür setze ich php://input ein.