HTTP Content Negotiation passt das server response Format im Hosting automatisch an die Wünsche des Clients an und wertet dafür Header wie Accept, Accept-Language und Accept-Encoding aus. So liefere ich je nach Header die beste Variante – etwa JSON statt XML, Gzip oder Brotli und die richtige Sprache – und stärke damit die web optimization spürbar.
Zentrale Punkte
Die folgenden Stichpunkte geben den schnellen Überblick, bevor ich die Umsetzung Schritt für Schritt erkläre.
- Header steuern Format, Sprache, Zeichensatz und Kompression.
- Server-driven Negotiation verkürzt Roundtrips und beschleunigt Auslieferung.
- Vary-Header verhindert Cache-Verwirrung und hält Varianten sauber getrennt.
- Fallbacks mit JSON/HTML und Status 406 sichern planbares Verhalten.
- q-Werte steuern Prioritäten, wenn mehrere Varianten möglich sind.
Was ist HTTP Content Negotiation im Hosting?
Ich nutze Content Negotiation, um eine Ressource in der bestmöglichen Variante auszuliefern, ohne mehrere Endpunkte zu bauen. Der Client sendet Vorlieben in Accept-, Accept-Language-, Accept-Charset- und Accept-Encoding-Headern, und ich antworte mit dem passenden server response Format. So erhält ein Browser etwa HTML, ein Bot JSON und ein Bild-Client WebP oder AVIF. In Hosting-Setups dominiert die servergetriebene Verhandlung, weil sie keine zusätzlichen Roundtrips auslöst und direkt auf die Header reagiert. Bleibt keine passende Variante übrig, antworte ich konsistent mit 406 Not Acceptable, damit Clients ein klares Signal bekommen.
Request- und Response-Header im Überblick
Für verlässliche Negotiation beachte ich immer zwei Seiten: Die eingehenden Request-Header mit Vorlieben und die ausgehenden Response-Header mit eindeutiger Kennzeichnung. Accept zeigt erlaubte Medientypen, Accept-Language bevorzugte Sprachen, Accept-Charset den Zeichensatz und Accept-Encoding mögliche Kompressionen. Ich setze die Antwort mit Content-Type, Content-Language, Content-Encoding und korrektem Vary-Header auf, damit Caches nicht falsche Varianten servieren. Der Vary-Header teilt Caches mit, an welchen Merkmalen sie Varianten unterscheiden müssen, etwa Vary: Accept, Accept-Language. Wer content negotiation http nutzt, sollte diese Header-Kombination konsequent pflegen, sonst entstehen Fehler im Cache.
| Header | Zweck | Beispiel | Wichtige Antwort | Cache-Hinweis |
|---|---|---|---|---|
| Accept | Erlaubte Medientypen | application/json; q=0.9, text/html; q=0.8 | Content-Type: application/json | Vary: Accept |
| Accept-Language | Bevorzugte Sprachen | de-DE, en-US; q=0.7 | Content-Language: de-DE | Vary: Accept-Language |
| Accept-Charset | Zeichensatz | utf-8 | Content-Type: text/html; charset=utf-8 | Vary: Accept-Charset |
| Accept-Encoding | Kompression | br, gzip; q=0.8 | Content-Encoding: br | Vary: Accept-Encoding |
Server-getrieben, client-getrieben und request-driven
Ich unterscheide drei Vorgehensweisen und wähle je nach Projekt das passende Modell. Server-driven (proaktiv) ist mein Standard, da der Server direkt anhand der Header entscheidet und sofort eine Variante zurückgibt. Client-driven (reaktiv) lässt den Client aus einer Liste auswählen, erzeugt aber Mehraufwand durch zusätzliche Requests. Request-driven mischt beides, etwa indem Parameter in der URL zusammen mit Accept-Headern zählen. Für Hosting-Umgebungen mit hoher Last überzeugt servergetriebenes Verhalten, weil es Roundtrips spart, Caches entlastet und eindeutige Regeln erlaubt.
Apache: .htaccess, MultiViews und Type-Maps
Auf Apache aktiviere ich MultiViews oder nutze Type-Maps, um Sprach- und Formatvarianten automatisch zu bedienen. MultiViews erlaubt Dateipaare wie index.html.de und index.html.en, die Apache anhand von Accept-Language auswählt. Für Medientypen setze ich q-Werte, sodass moderne Formate Priorität erhalten, etwa image/webp vor image/jpeg. Ich achte immer darauf, Vary korrekt zu setzen und 406 zu liefern, wenn Clients ein nicht unterstütztes Format fordern. So bleibt das Verhalten vorhersehbar und Caches speichern keine widersprüchlichen Antworten.
# .htaccess
Options +MultiViews
# Beispiel für Type-Map (datei.var)
URI: bild
Content-type: image/webp; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-language: de
# Sprachen-Variante automatisch bedienen
# Dateien: index.html.de, index.html.en
Nginx: map, Lua und Edge-Logik
Unter Nginx setze ich häufig map-Direktiven ein, um Accept-Header auszuwerten und passende Endpunkte zuzuordnen. Für APIs leite ich je nach Accept zwischen HTML und JSON um, optional ergänzt um Lua für feinere Regeln. Ich behalte den Vary-Header im Blick, denn Caches müssen Entscheidungen an Accept und Accept-Language koppeln. In verteilten Setups verlagere ich Teile der Negotiation an Edge-Knoten, um Latenzen gering zu halten. Wichtig bleibt eine Whitelist, damit ich nur geprüfte Medientypen anbiete und nicht auf exotische Formate hereinfalle.
# nginx.conf (Auszug)
map $http_accept $fmt {
default "html";
"~*application/json" "json";
"~*\\*/\\*" "json";
}
server {
add_header Vary "Accept, Accept-Language";
location /api {
try_files $uri $uri/ /api.$fmt;
}
}
Caching, Vary und SEO-Signale
Ohne korrekten Vary-Header verhalten sich Caches unvorhersehbar und liefern falsche Varianten an andere Nutzer. Ich setze Vary exakt auf die Header, nach denen ich unterscheide, also typischerweise Accept, Accept-Language und Accept-Encoding. Das stärkt nicht nur die Konsistenz, sondern sendet auch klare Signale für Performance, was indirekt SEO-Vorteile bringt. Wer tiefer in Header-Strategien einsteigt, profitiert von diesem Leitfaden zu HTTP-Header für Performance und SEO. Zusätzlich prüfe ich, ob der Cache-Key des CDN diese Dimensionen abbildet, damit Edge-Nodes richtige Objekte vorhalten.
APIs: Formate whitelisten und sauber fallbacken
Bei APIs halte ich die unterstützten Medientypen in einer Whitelist fest, beispielsweise application/json und application/xml. Fehlt der Accept-Header oder passt nichts, liefere ich JSON als Default, da es am breitesten unterstützt ist. Fragt ein Client explizit ein unbekanntes Format an, antworte ich mit 406 Not Acceptable, statt stillschweigend zu raten. Profileinstellungen eines Nutzers haben dabei Vorrang vor Accept, wenn die Anwendung das so vorsieht. Diese Regeln sorge ich zentral, reproduzierbar und mittels Tests abgesichert, damit Integrationen stabil bleiben.
Sprachen, Zeichensätze und Barrierefreiheit
Für Mehrsprachigkeit setze ich Accept-Language ein, um Sprachvarianten automatisch zu wählen und Content-Language in der Antwort zu kennzeichnen. Ich formuliere Fallbacks klar: Gibt es die gewünschte Sprache nicht, nehme ich eine definierte Standardsprache. Mit Accept-Charset stelle ich sicher, dass UTF-8 überall gilt, damit Sonderzeichen konsistent erscheinen. Auch Screenreader profitieren von korrekten Sprachangeben in Content-Language und lang-Attributen im Markup. So bleibt die Auslieferung inklusiv, transparent und technisch sauber.
Bilder, Kompression und Medientypen
Bei Bildern gönne ich modernen Formaten einen Vorsprung und beachte die Accept-Header von Browsern. Unterstützt der Client AVIF oder WebP, liefere ich diese Versionen bevorzugt aus, sonst fällt die Wahl auf JPEG oder PNG. Für Entscheidungen zwischen WebP und AVIF hilft mir dieser praxisnahe WebP vs AVIF Vergleich. Zusätzlich reduziere ich die Datenmenge deutlich über Accept-Encoding mit Brotli oder Gzip, in der Praxis oft bis zu 50 %. Das schont Bandbreite, verkürzt Time-to-First-Byte und stabilisiert die wahrgenommene Geschwindigkeit.
Messen, testen, ausrollen
Ich messe den Effekt der Negotiation laufend, sonst bleiben Potenziale ungenutzt. Mit curl prüfe ich Varianten, etwa curl -H „Accept: application/json“ oder curl -H „Accept-Language: de“. In Logs kontrolliere ich Trefferquoten pro Variante und gleiche sie mit CDN-Statistiken ab. Für Encoding-Strategien und Brotli-Grade vergleiche ich Ergebniskurven, bevor ich Vorgaben global setze. Einen kompakten Einstieg in Setup und Tuning liefert mir dieser Leitfaden zum HTTP-Kompression konfigurieren, den ich parallel zur Negotiation abstimme.
Fehlercodes und Edge-Cases in der Praxis
Ich unterscheide sauber zwischen 406 Not Acceptable und 415 Unsupported Media Type: 406 setze ich, wenn die Antwort nicht in einer akzeptierten Variante vorliegt (Accept verweigert); 415 nutze ich, wenn die Anfrage einen nicht unterstützten Medientyp sendet (Content-Type der Request-Payload). In seltenen Fällen ist 300 Multiple Choices sinnvoll, wenn ich dem Client mehrere exakt passende Varianten anbieten will – praktisch nutze ich aber in Hochlast-Umgebungen klare Defaults statt interaktiver Auswahl. Bei Caching antworte ich weiterhin mit 304 Not Modified pro Variante; ETag und Last-Modified gelten stets variantenspezifisch. Fehlt Accept komplett, werte ich das als „alles ist erlaubt“ und bediene den definierten Default (meist JSON für APIs, HTML für Webseiten). Setzt ein Client q=0 für einen Typ, schließe ich diese Variante explizit aus.
Sicherheit: Sniffing, Whitelists und Inputhygiene
Ich lasse den Content-Type nicht vom Browser „erraten“, sondern liege mit konsistentem Content-Type und X-Content-Type-Options: nosniff fest. In der Negotiate-Logik akzeptiere ich nur whitelisted Types/Sprachen und begrenze Headerlängen, damit ungewöhnlich lange Accept-Language-Listen keine Ressourcen binden. Für Logs und Metriken bereinige ich Headerwerte, um Injection-Risiken zu vermeiden. Außerdem beachte ich Datenschutz: Accept-Language kann Rückschlüsse auf Nutzer zulassen; ich speichere nur so viel wie nötig und aggrehiere für Statistiken. Bei CORS lasse ich Negotiation unabhängig entscheiden – Cross-Origin-Regeln binde ich getrennt an Origin/Methods/Headers, nicht an Accept-Varianten, damit ich keine unbeabsichtigten Freigaben erzeuge.
CDN, Cache-Keys und ETags pro Variante
Bei CDNs definiere ich den Cache-Key bewusst variantenfähig. Neben URL gehören dort Accept, Accept-Language und Accept-Encoding hinein, exakt so, wie ich im Vary-Header signalisiere. Ich setze pro Variante eigene ETags (z. B. Hash mit Suffix „.json.de.br“) und stelle sicher, dass Conditional Requests korrekt funktionieren. Für statische Assets arbeite ich mit vorab erzeugten, komprimierten Dateien (br/gz), die das CDN 1:1 dient. Um Origin-Last zu senken, nutze ich „collapsed forwarding“ oder „stale-while-revalidate“: Der erste Miss aktualisiert, alle anderen bekommen eine frische oder „stale acceptable“ Variante. Range-Requests kombiniere ich nur mit Kompression, wenn Server und CDN das Feature konsistent handeln; andernfalls deaktiviere ich Range für dynamisch komprimierte Antworten, um Fragmentierung der Varianten zu vermeiden.
q-Werte, Wildcards und Matching-Algorithmus
Treffen mehrere Varianten zu, sortiere ich nach q-Werten und Präzision: exakter Typ/Subtyp schlägt Typ/*, beide schlagen */*. Bei gleichem q gewinnt die spezifischere Variante. Setzt der Client keinen q-Wert, interpretiere ich ihn als 1.0. Mit q=0 schließt der Client einen Typ ausdrücklich aus. Für Bilder und Dokumente gebe ich modernen Formaten mit leicht höherem q den Vorzug, biete aber Fallbacks, wenn der Client z. B. AVIF nicht kennt.
# Pseudocode für Accept-Matching
parse acceptHeader into candidates (type, subtype, q)
for variant in serverVariants:
score = 0
for cand in candidates:
if cand.type == variant.type and cand.subtype == variant.subtype:
score = max(score, 1000 * cand.q + 2) # exakt
elif cand.type == variant.type and cand.subtype == "*":
score = max(score, 1000 * cand.q + 1) # Typ/*
elif cand.type == "*" and cand.subtype == "*":
score = max(score, 1000 * cand.q) # */*
assign best score
choose variant with highest score or 406 wenn alle Scores 0
Ähnlich verfahre ich bei Accept-Language: „de-CH“ priorisiert „de-CH“ vor „de“, erst dann fällt die Wahl auf den globalen Default. Ich halte die Auswahl deterministisch, damit Caches verlässliche Objekte ablegen.
Framework-Beispiele: Express/Node und Go
In Anwendungs-Frameworks kapsle ich die Regeln in Middleware, setze Vary konsistent und halte Fallbacks zentral.
// Express/Node (vereinfacht)
const vary = require('vary');
function negotiate(req, res, next) {
vary(res, 'Accept, Accept-Language, Accept-Encoding');
const types = req.accepts(['json', 'html']);
const lang = req.acceptsLanguages(['de', 'en']) || 'de';
res.set('Content-Language', lang);
if (!types) return res.status(406).send('Not Acceptable');
if (types === 'json') {
res.type('application/json; charset=utf-8');
return res.json({ ok: true, lang });
}
res.type('text/html; charset=utf-8');
res.send(`<html lang="${lang}">OK</html>`);
}
app.get('/resource', negotiate);
// Go net/http (vereinfacht)
func negotiateJSON(r *http.Request) bool {
a := r.Header.Get("Accept")
if a == "" || strings.Contains(a, "*/*") { return true }
if strings.Contains(strings.ToLower(a), "application/json") { return true }
return false
}
func handler(w http.ResponseWriter, r *http.Request) {
w.Header().Add("Vary", "Accept, Accept-Language, Accept-Encoding")
if !negotiateJSON(r) {
w.WriteHeader(http.StatusNotAcceptable)
w.Write([]byte("Not Acceptable"))
return
}
w.Header().Set("Content-Type", "application/json; charset=utf-8")
io.WriteString(w, `{"ok":true}`)
}
Wichtig ist, dass ich mich nie auf User-Agent verlasse, sondern ausschließlich auf explizite Accept*-Header. Das macht Verhalten reproduzierbar und testbar.
Internationalisierung im Detail
Ich baue eine klare Fallback-Kette auf, z. B. de-CH → de-DE → de → Default. Existiert ein Region-Code nicht, breche ich ihn auf die Basissprache herunter. In der Antwort kennzeichne ich mit Content-Language exakt die gewählte Variante und vermeide Mischformen. Nutzerpräferenzen (etwa Account-Locale) haben Vorrang vor Accept-Language, werden aber ebenfalls deterministisch auf Sprachen gemappt, die das System wirklich bereitstellt. Für SEO und Barrierefreiheit achte ich darauf, dass lang-Attribute im HTML und Content-Language konsistent sind; außerdem verhindere ich Redirect-Schleifen, indem ich die Entscheidung serverseitig treffe und Caches korrekt via Vary anweise.
Request-driven Varianten sauber kanonisieren
Kombiniere ich URL-Parameter (z. B. ?format=json) mit Accept, braucht die Seite eine eindeutige Kanonisierung: Entweder akzeptiere ich den Parameter als harte Vorgabe und ignoriere Accept, oder der Parameter ist nur ein Hint, der durch Accept überstimmt werden kann. Ich dokumentiere die Regel klar und setze in der Antwort konsistente Header, damit Caches nicht zwei unterschiedliche Repräsentationen derselben URL ohne trennenden Vary-Schlüssel speichern. Für HTML-Seiten sorge ich zusätzlich für eine eindeutige kanonische Adresse pro Sprach-/Formatvariante innerhalb des Systems, damit Analysen und Monitoring keine Duplikate zählen.
Kompression feinjustieren und vorproduzieren
Bei dynamischen Antworten balanciere ich CPU-Kosten der Kompression gegen die Netzwerkersparnis. Brotli auf Stufe 4–6 liefert typischerweise ein gutes Verhältnis; höhere Stufen lohnen sich vor allem für statische Assets, die ich vorab komprimiere. Ich halte für große Dateien sowohl br als auch gzip bereit, weil nicht alle Clients Brotli unterstützen. In der Praxis speichere ich die Precompiles mit Dateiendungen (.br/.gz), lasse den Server anhand von Accept-Encoding und Dateigrößenschwellen entscheiden und setze Content-Encoding korrekt. Wichtig: Jede komprimierte Variante bekommt ihren eigenen ETag; Andernfalls liefern Conditional Requests falsche 304-Antworten aus.
Beobachtbarkeit, Canary und Rollback
Ich führe Negotiation-Regeln mit Feature-Flags ein, aktiviere sie schrittweise (z. B. 5 %, 25 %, 100 %) und überwache Kennzahlen pro Variante: Fehlerquote, Latenz, Bytes out, Cache-Hitrate, Anteil 406/415. In den Logs vermerke ich die gewählte Variante sowie die auslösenden Header (aggregiert), damit ich Fehlzuordnungen schnell finde. Für Tests nutze ich synthetische Prüfer, die bekannte Accept-Kombinationen regelmäßig gegen Staging und Produktion fahren. Bei Auffälligkeiten rolle ich gezielt Varianten zurück, ohne das Gesamtsystem zu stoppen – etwa indem ich AVIF temporär deaktiviere, JSON als Default erzwinge oder die Vary-Dimension reduziere, bis der Cache sich erholt.
Kurzfazit: Das richtige Response-Format zahlt sich aus
Ich liefere schneller aus, spare Bandbreite und erhöhe die Zufriedenheit, wenn ich Content Negotiation konsequent nutze. Die Kombination aus Accept-Headern, klaren Fallbacks, q-Werten und Vary sorgt für stabile, reproduzierbare Antworten. In der Praxis priorisiere ich servergetriebene Entscheidungen, halte Caches variantenfähig und teste jede Regel mit curl. APIs bekommen eine strenge Whitelist, Webseiten profitieren von Sprach- und Bildvarianten sowie moderner Kompression. So erreicht das Projekt messbare Vorteile in Performance, Barrierefreiheit und Wartbarkeit – mit einem Setup, das ich zielgerichtet steuere und jederzeit nachvollziehen kann.
