Ein Login klappt in Postman, aber nicht im Browser. Ein API-Endpoint funktioniert lokal, aber im Deployment kommt plötzlich ein 401 oder 415. Oder ein Bild wird geliefert, aber mit falschem Cache-Verhalten. Solche Probleme haben oft eine gemeinsame Ursache: HTTP-Header. Genauer gesagt: Request-Header, die der Client (Browser, App, Script) an den Server sendet.
Request-Header sind Metadaten zur Anfrage. Sie beschreiben zum Beispiel, welche Datenformate akzeptiert werden, ob Cookies mitgeschickt werden dürfen oder welche Art von Authentifizierung genutzt wird. Wer diese Felder sauber versteht, findet Fehler schneller, baut stabilere APIs und vermeidet unnötige Sicherheitsrisiken.
Welche Fragen Request-Header in der Praxis beantworten
Request-Header wirken abstrakt, sind aber sehr konkret. Im Alltag beantworten sie vor allem diese typischen Fragen:
- Welches Format erwartet der Client als Antwort (z. B. JSON oder HTML)?
- Welches Format sendet der Client im Body (z. B. JSON, Form-Daten)?
- Wer stellt die Anfrage (Browser, Script, Mobile-App)?
- Ist die Anfrage authentifiziert (Token, Cookie, Basic Auth)?
- Darf der Browser diese Anfrage ausfĂĽhren (CORS)?
- Kann eine Antwort aus dem Cache kommen oder muss sie frisch sein?
Gerade bei APIs lohnt sich ein kurzer Blick auf verwandte Themen wie Statuscodes und Fehlermeldungen. Passend dazu hilft API-Design mit Statuscodes, um Request- und Response-Seite zusammenzudenken.
Die wichtigsten Request-Header: Ăśberblick in einer Tabelle
Die folgende Tabelle zeigt Felder, die in Debugging-Sessions besonders oft relevant sind. Nicht jeder Header ist immer nötig, aber diese Namen sollten sitzen.
| Header | WofĂĽr er steht | Typischer Effekt / Stolperfalle |
|---|---|---|
| Content-Type | Format des Request-Bodys | Falscher Wert fĂĽhrt oft zu 415 (Unsupported Media Type) oder leeren Body-Daten |
| Accept | Erlaubte/gewĂĽnschte Response-Formate | Wenn API nur JSON liefert, aber Client HTML erwartet, entstehen Parsing-Fehler |
| Authorization | Authentifizierung (z. B. Bearer Token) | Fehlender/abgelaufener Token verursacht 401; falsches Schema fĂĽhrt zu 403/401 |
| Cookie | Session-/State-Informationen | Cookies fehlen bei CORS oder falschem SameSite; Login wirkt „vergessen“ |
| Origin | Ursprung der Anfrage (Schema+Host+Port) | Wichtig bei CORS; Server entscheidet, ob Browser-Anfrage erlaubt ist |
| Referer | Seite, von der aus die Anfrage kam | Wird teils gekĂĽrzt; nicht als Sicherheitsanker missbrauchen |
| User-Agent | Client-Identifikation | Kann gefälscht werden; höchstens für Diagnose/Analytics nutzen |
| If-None-Match | Cache-Validierung per ETag | Server kann 304 liefern; spart Daten, wirkt aber „alte Daten“ wenn falsch gehandhabt |
Content-Type & Accept richtig einsetzen (und nicht verwechseln)
Content-Type: Was steckt im Request-Body?
Content-Type beschreibt das Format, das im Request-Body tatsächlich gesendet wird. Typische Werte sind
application/json
(JSON),
application/x-www-form-urlencoded
(klassische Formulare) oder
multipart/form-data
(Datei-Uploads).
Ein häufiger Fehler: Der Client sendet JSON, aber setzt keinen Content-Type. Manche Frameworks versuchen dann, den Body nicht als JSON zu parsen. Ergebnis: Felder sind leer oder Validierung schlägt an, obwohl „Daten gesendet“ wurden.
Accept: Was darf in der Antwort zurĂĽckkommen?
Accept beschreibt, welche Formate der Client in der Response verarbeiten kann. In APIs ist häufig
application/json
sinnvoll. Browser schicken oft eine lange Liste, weil sie HTML, Bilder und vieles mehr akzeptieren.
Praktischer Tipp: Bei API-Clients (Fetch, Axios, Postman) ist es oft sinnvoll, Accept explizit zu setzen, damit klar ist, dass JSON erwartet wird. Das reduziert Missverständnisse, wenn ein Server im Fehlerfall doch HTML ausliefert (z. B. eine Error-Page des Proxys).
Mini-Check: „Warum kommt HTML statt JSON?“
- PrĂĽfen, ob Accept auf JSON steht.
- PrĂĽfen, ob ein Reverse Proxy (z. B. Nginx) eigene Fehlerseiten liefert.
- Im Network-Tab auch Response-Header ansehen (Content-Type der Antwort).
Authorization & Cookie: zwei Wege zur Anmeldung
Authorization: Token-basierte Authentifizierung
Authorization ist der Standard-Header, um Zugangsdaten mitzusenden. Bei modernen APIs ist das oft ein Bearer-Token, zum Beispiel:
Authorization: Bearer <token>
.
Typische Fehlerbilder:
- Token fehlt: Server antwortet mit 401.
- Token ist abgelaufen: ebenfalls häufig 401 (je nach Implementierung).
- Falsches Schema (z. B. „Token“ statt „Bearer“): Server erkennt den Wert nicht.
Wer Authentifizierung mit Tokens plant, sollte auch verstehen, wie Tokens aufgebaut sind und wo typische Risiken liegen. Dazu passt JWT-Authentifizierung – sicher implementieren.
Cookie: Sessions und „eingeloggter Browser“
Cookie ist der Request-Header, in dem der Browser gespeicherte Cookies automatisch mitsendet. Das wird häufig für Session-IDs genutzt (klassisches Login). Der Client schreibt hier normalerweise nicht manuell, sondern der Browser verwaltet das.
In der Praxis entstehen Probleme oft an diesen Stellen:
- Cross-Site-Requests: Cookies werden je nach SameSite-Regeln nicht gesendet.
- CORS: Cookies kommen nur, wenn Client und Server korrekt konfiguriert sind (Credentials).
- Subdomain-Setup: Domain/Path der Cookies passt nicht zum API-Host.
Origin & CORS: warum der Browser „blockt“, aber curl nicht
Origin: der Auslöser für CORS-Entscheidungen
Der Header Origin enthält den Ursprung der Anfrage (Schema, Host, Port). Er wird vor allem bei Cross-Origin-Requests gesetzt, also wenn Frontend und Backend nicht denselben Ursprung haben.
Wichtig: CORS ist keine „Server-Sicherheit“ im klassischen Sinne, sondern eine Browser-Regel. Ein Server kann Requests von überall bekommen, aber der Browser entscheidet, ob die Response an JavaScript weitergegeben wird.
Preflight (OPTIONS) kurz erklärt
Bei bestimmten Requests führt der Browser zuerst einen Preflight-Request aus (eine OPTIONS-Anfrage), um zu klären, ob der eigentliche Request erlaubt ist. Das passiert oft bei nicht-trivialen Requests, etwa mit Authorization-Header oder bestimmten Content-Types.
Wenn hier etwas nicht passt, sieht es so aus, als sei „die API kaputt“, obwohl der Server eigentlich erreichbar ist. Im Network-Tab hilft es, gezielt nach OPTIONS zu schauen und die Response-Header zu prüfen.
Cache-Header bei Requests: If-None-Match schnell einordnen
If-None-Match: „Hast du eine neuere Version?“
Wenn ein Server ETags nutzt, kann der Client bei späteren Requests
If-None-Match
mitsenden. Der Server vergleicht dann, ob sich die Ressource geändert hat. Ist sie identisch, kann er 304 (Not Modified) antworten, ohne die Inhalte erneut zu schicken.
Das ist gut für Performance, kann aber irritieren, wenn während Entwicklung „alte“ Inhalte erscheinen. Dann hilft es, Cache zu deaktivieren oder die ETag-Logik zu prüfen. Wer Cache-Control und ETags sauber verstehen möchte, findet eine passende Vertiefung in HTTP Caching: Cache-Control und ETag richtig nutzen.
So geht’s: Request-Header systematisch debuggen
- Im Browser (DevTools → Network) den konkreten Request öffnen und Request Headers ansehen.
- PrĂĽfen, ob Content-Type zum gesendeten Body passt (JSON, Form, Upload).
- Accept setzen und kontrollieren, ob die Response wirklich das erwartete Format hat.
- Bei 401/403: Authorization-Header prĂĽfen (Schema, Token vorhanden, Token aktuell).
- Bei „eingeloggt in Tab A, ausgeloggt in Tab B“: Cookie-Domain/Path und SameSite prüfen.
- Bei CORS-Problemen: OPTIONS-Preflight suchen und die erlaubten Header/Origins vergleichen.
- Bei „komischen“ Datenständen: If-None-Match/Cache-Verhalten testen (Cache aus, Hard Reload).
FAQ: häufige Fragen zu HTTP-Request-Headern
Warum sollte Content-Type und Accept beide gesetzt werden?
Weil sie zwei unterschiedliche Richtungen beschreiben: Content-Type sagt, was im Request drin ist. Accept sagt, was als Antwort verarbeitet werden kann. Das sauber zu trennen verhindert Parsing-Fehler und Missverständnisse.
Kann User-Agent fĂĽr Sicherheit genutzt werden?
Nein, dafür ist er nicht geeignet. Der Wert ist leicht fälschbar und sollte höchstens für Diagnose, Logging oder grobe Kompatibilitätsentscheidungen dienen.
Warum funktioniert der Request in curl/Postman, aber nicht im Browser?
Meistens wegen CORS oder Cookies. curl/Postman unterliegen nicht den Browser-CORS-Regeln. Im Browser entscheidet der Origin-Header zusammen mit der Serverkonfiguration, ob JavaScript die Response nutzen darf.
Was ist ein „Preflight“-Request in einfachen Worten?
Ein kurzer Vorab-Check des Browsers per OPTIONS-Anfrage. Der Browser fragt damit: „Darf ich gleich den eigentlichen Request mit diesen Methoden/Headers senden?“
Empfehlung der Redaktion: diese Header zuerst prĂĽfen
Wenn ein Request „unerklärlich“ wirkt, lohnt sich eine feste Reihenfolge. In den meisten Projekten führen diese vier Felder am schnellsten zur Ursache: Content-Type, Accept, Authorization und Cookie. Danach sind Origin/CORS und Cache-Header gute Kandidaten.
Für stabilere APIs hilft es außerdem, Fehler konsequent zu strukturieren und verständlich zurückzugeben. Dazu passt API-Fehler richtig behandeln als ergänzende Praxislektüre.
