#headers

Erstellen Sie korrekte CORS-Antwortheader und bewerten Sie Preflight-Anfragen – ohne jedes Mal die Spezifikation erneut lesen zu müssen. Der Headers-Endpunkt wandelt eine einfache Richtlinie (erlaubte Ursprünge, Methoden, Anfrageheader, ob Anmeldeinformationen erlaubt sind, eine Preflight-Max-Age und alle offengelegten Antwortheader) in die genaue Menge der Access-Control-*-Header um, die zurückgegeben werden sollen, und behandelt die Teile, die Leute falsch machen: Sie können einen Wildcard-Ursprung nicht mit Anmeldeinformationen kombinieren, daher spiegelt er den spezifischen Anfrageursprung wider und fügt stattdessen Vary: Origin hinzu; er lässt den Allow-Origin-Header weg, wenn ein Ursprung nicht in Ihrer Liste ist; und er warnt, wenn eine Konfiguration sich nicht wie erwartet verhalten würde. Der Check-Endpunkt nimmt eine eingehende Anfrage – ihren Ursprung, die (angeforderte) Methode und die Access-Control-Request-Headers – und teilt Ihnen mit, ob sie CORS bestehen würde, den genauen Grund, wenn sie fehlschlägt, und die Antwortheader, die Sie zurücksenden sollten. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für API-Gateways und Backends, Edge- und Serverless-Funktionen, Debugging von Browser-CORS-Fehlern und die genaue Einhaltung einer Sicherheitsrichtlinie. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts gespeichert. 3 Endpunkte. Dies erstellt und prüft die Header; es führt keine Cross-Origin-Anfrage durch – um die Sicherheitsheader einer Live-Site zu überprüfen, verwenden Sie eine Security-Headers-API.

api.oanor.com/cors-api

Analysieren und Erstellen von HTTP-Content-Disposition-Headern (RFC 6266, mit RFC 5987 filename*-Kodierung). Der Parse-Endpunkt liest einen Header in seinen Dispositionstyp (attachment, inline oder form-data), seinen Dateinamen – korrekt dekodiert die erweiterte Form filename*=UTF-8''… und bevorzugt diese gegenüber einem einfachen Dateinamen genau wie von der Spezifikation gefordert – den Formularfeldnamen und alle verbleibenden Parameter. Der Build-Endpunkt erstellt einen korrekten Header aus einfachen Feldern und gibt bei einem Dateinamen mit Nicht-ASCII-Zeichen (Akzente, Emojis, CJK) automatisch sowohl einen ASCII-Fallback-Dateinamen als auch den prozentkodierten filename* aus, sodass jeder Browser den richtigen Download-Namen anzeigt, während ältere Clients weiterhin funktionieren. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat – es wird nie eine Datei abgerufen oder gespeichert. Ideal für Datei-Download- und Upload-Endpunkte, Objektspeicher und CDNs, Content-Gateways und Proxys, E-Mail- und Multipart-Verarbeitung sowie zum Debuggen, warum ein Download falsch benannt ist. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts gespeichert. 3 Endpunkte. Dies erstellt und analysiert die Header-Zeichenfolge selbst; es stellt keine Datei bereit.

api.oanor.com/contentdisposition-api

Analysieren und Erstellen von HTTP-Cache-Control-Headern (RFC 9111). Der Parse-Endpunkt wandelt einen Cache-Control-Header in strukturierte, benannte Direktiven um – public und private, no-store, no-cache, no-transform, max-age und s-maxage, must-revalidate und proxy-revalidate, immutable, stale-while-revalidate, stale-if-error, min-fresh und max-stale – zusammen mit einer kurzen Zusammenfassung: ob die Antwort cachebar ist, ob sie vor der Verwendung erneut validiert werden muss, ihre Sichtbarkeit (public oder private) und ihr max-age in Sekunden. Der Build-Endpunkt setzt einen korrekten, kanonisch geordneten Header aus einfachen booleschen und numerischen Feldern zusammen, validiert, dass die sekundenbasierten Direktiven nicht-negative Ganzzahlen sind, und zitiert Feldlistenformen von no-cache und private. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für CDN- und Edge-Konfiguration, Caching-Proxys und Reverse-Proxys, API-Antworten und statische Asset-Anpassung sowie zum Debuggen, warum eine Antwort gecached wird (oder nicht). Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts gespeichert. 3 Endpunkte. Dies erstellt und analysiert die Header-Zeichenfolge selbst; es ruft keine URL ab.

api.oanor.com/cachecontrol-api

Analysieren und Erstellen von RFC 8288 HTTP-Link-Headern (Web Linking). Der Parse-Endpunkt wandelt einen Link-Header in eine strukturierte Liste um – jeder Link mit seiner URI, seiner rel-Beziehung(en) und allen Zielattributen (title, type, hreflang, media, anchor) – und gibt auch eine praktische rel→uri-Zuordnung zurück, sodass Sie die nächsten, vorherigen, ersten und letzten URLs für die API-Paginierung in einem Schritt abrufen können. Es behandelt korrekt die schwierigen Teile: mehrere durch Kommas getrennte Links, Kommas innerhalb von spitzen Klammern umschlossenen URIs, in Anführungszeichen gesetzte Parameterwerte, mehrere durch Leerzeichen getrennte rel-Token und RFC 8187 erweiterte Werte. Der Build-Endpunkt erstellt einen korrekten Link-Header aus einem oder mehreren Link-Objekten (oder einer einzelnen URI + rel mit optionalen Attributen) und setzt Werte nur bei Bedarf in Anführungszeichen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für paginierte REST-APIs und Clients, Hypermedia und HATEOAS, HTTP-Preload/Prefetch-Hinweise, Feed- und Alternativformat-Erkennung, Proxys und Gateways. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts gespeichert. 3 Endpunkte. Dies erstellt und analysiert den Link-Header-String selbst; es ruft keine URL ab.

api.oanor.com/linkheader-api

HTTP-Inhaltsaushandlung als API. Der Parse-Endpunkt liest einen Accept-, Accept-Language-, Accept-Encoding- oder Accept-Charset-Header – mit Qualitätswerten (q) und Parametern – in eine saubere Liste, geordnet nach den Präferenzen des Clients. Der Negotiate-Endpunkt nimmt diesen Header sowie die Liste der Werte, die Ihr Server tatsächlich ausliefern kann, und gibt die beste Übereinstimmung zurück, zusammen mit der vollständig sortierten Liste und dem Eintrag, der mit jedem Kandidaten übereinstimmt. Dabei werden die korrekten Regeln für jeden Typ angewendet: Media-Typ- und Subtyp-Wildcards (text/*, */*), RFC 4647-Sprachbereichsabgleich (eine Anfrage nach en passt auf Ihr en-US, und en-US fällt auf en zurück) sowie exakter Abgleich mit einem *-Wildcard für Kodierungen und Zeichensätze – und ein q=0-Eintrag lehnt einen Wert korrekt ab. Alles läuft lokal und deterministisch, daher ist es sofort und privat. Ideal für i18n-Middleware und Locale-Auswahl, API-Versionierung nach Medientyp, Antwortformat- und Komprimierungsauswahl, CDNs, Proxys und Edge-Funktionen. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Service, sofort. Live, nichts wird gespeichert. 3 Endpunkte. Dies handelt HTTP-Header aus; um ein einzelnes BCP-47-Sprachtag zu validieren oder zu zerlegen, verwenden Sie eine BCP-47-API.

api.oanor.com/negotiate-api

Analysieren und Erstellen von HTTP-Cookies. Der Parse-Endpunkt liest einen Set-Cookie-Header in seinen Namen, Wert und strukturierte Attribute aus — Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Priority und Partitioned — oder, mit mode=cookie, teilt einen Request-Cookie-Header wie "a=1; b=2; c=3" in eine geordnete Liste und eine Name→Wert-Zuordnung auf. Der Serialize-Endpunkt erstellt einen korrekten Set-Cookie-String aus einfachen Feldern, mit sinnvollen Standardwerten (Path=/), korrekter Datumsformatierung für Expires, optionaler URL-Kodierung des Werts und Validierung des Cookie-Namens, des Datums und der Enum-Attribute — und fügt automatisch Secure hinzu, wenn SameSite=None, wie es Browser verlangen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Web-Frameworks und Middleware, API-Debugging und Proxys, Sitzungs- und Einwilligungstools, Tests und Sicherheitsüberprüfungen. Reine lokale Berechnung — kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts wird gespeichert. 3 Endpunkte. Dies analysiert und erstellt Cookie-Strings; es ruft keine URL ab — um die Antwort-Header einer Live-Seite zu überprüfen, verwenden Sie eine Security-Headers- oder HTTP-API.

api.oanor.com/cookie-api

Eine saubere, programmatische Referenz für HTTP-Semantik, basierend auf den offiziellen IANA-Registern. Schlagen Sie jeden Statuscode mit seiner Begründung und Klasse nach (404 → Not Found, Client Error; 503 → Service Unavailable, Server Error), listen Sie eine ganze Klasse auf (4xx, 5xx…); schlagen Sie jede Methode mit ihren Safe/Idempotent-Flags nach (GET → safe + idempotent, POST → keines, DELETE → idempotent); oder schlagen Sie die 255 registrierten HTTP-Header-Felder (Content-Type, Authorization, …) mit ihrem Registrierungsstatus nach oder durchsuchen Sie sie. Ideal für API-Tooling, HTTP-Clients, Dokumentation, Linter, Lernressourcen und Fehlerseiten.

api.oanor.com/http-api