Plesk-webbserver

Förhandling om HTTP-innehåll i hosting: Optimalt svarsformat för servern

Förhandling av HTTP-innehåll passar svar från server formatet i hostingen anpassar sig automatiskt till kundens krav och utvärderar headers som Accept, Accept-Language och Accept-Encoding. Beroende på header levererar jag den bästa varianten - till exempel JSON istället för XML, Gzip eller Brotli och rätt språk - och stärker därmed webboptimering märkbar.

Centrala punkter

Följande huvudpunkter ger en snabb överblick innan jag förklarar implementeringen steg för steg.

Huvud kontrollformat, språk, teckenuppsättning och komprimering.
Server-driven Förhandling förkortar rundresor och påskyndar leveranser.
Vary-rubrik förhindrar förväxling av cache och håller varianterna rent åtskilda.
Fallbackar med JSON/HTML och status 406 säkerställer ett förutsägbart beteende.
q-värden kontrollprioriteringar om flera varianter är möjliga.

Vad är HTTP-innehållsförhandling i hosting?

Jag använder Förhandling av innehåll, för att leverera en resurs i bästa möjliga variant utan att bygga flera slutpunkter. Klienten skickar preferenser i Accept-, Accept-Language-, Accept-Charset- och Accept-Encoding-rubrikerna, och jag svarar med lämplig svar från server format. En webbläsare tar t.ex. emot HTML, en bot JSON och en bildklient WebP eller AVIF. I värdkonfigurationer dominerar serverstyrd förhandling eftersom den inte utlöser några ytterligare rundresor och svarar direkt på rubrikerna. Om ingen lämplig variant återstår svarar jag konsekvent med 406 Not Acceptable så att klienterna får en tydlig signal.

En överblick över rubrikerna för begäran och svar

För tillförlitliga förhandlingar uppmärksammar jag alltid två sidor: Den inkommande Huvud för begäran med inställningar och de utgående svarshuvudena med unik märkning. Accept visar tillåtna mediatyper, Accept-Language föredragna språk, Accept-Charset teckenuppsättningen och Accept-Encoding möjliga komprimeringar. Jag konfigurerar svaret med Content-Type, Content-Language, Content-Encoding och den korrekta Vary-rubriken så att cacher inte serverar felaktiga varianter. Vary-headern talar om för cacher vilka egenskaper de behöver använda för att skilja mellan olika varianter, till exempel Vary: Accept, Accept-Language. Om du använder http med innehållsförhandling bör du upprätthålla denna rubrikkombination konsekvent, annars kommer fel att uppstå i cacheminnet.

Huvud	Syfte	Exempel	Viktigt svar	Cache-hint
Acceptera	Tillåtna medietyper	application/json; q=0,9, text/html; q=0,8	Innehållstyp: application/json	Vary: Acceptera
Acceptera språk	Önskade språk	de-DE, en-US; q=0,7	Innehållsspråk: de-DE	Vary: Accept-Language
Acceptera charset	Teckenuppsättning	utf-8	Innehållstyp: text/html; charset=utf-8	Vary: Acceptera charset
Accept-Encoding	Kompression	br, gzip; q=0,8	Innehållskodning: br	Vary: Acceptera-kodning

Serverstyrd, klientstyrd och förfrågningsstyrd

Jag skiljer mellan tre olika tillvägagångssätt och väljer, beroende på projekt, det lämplig Modell. Serverdriven (proaktiv) är min standard, eftersom servern beslutar direkt baserat på rubrikerna och omedelbart returnerar en variant. Client-driven (reaktiv) låter klienten välja från en lista, men genererar extra arbete på grund av ytterligare förfrågningar. Request-driven blandar båda, till exempel genom att räkna parametrar i URL:en tillsammans med Accept-headers. För hostingmiljöer med hög belastning är det serverdrivna beteendet övertygande eftersom det sparar rundresor, avlastar cacher och möjliggör tydliga regler.

Apache: .htaccess, MultiViews och typkartor

På Apache aktiverar jag MultiViews eller använda typkartor för att automatiskt servera språk- och formatvarianter. MultiViews tillåter filpar som index.html.de och index.html.en, som Apache väljer baserat på Accept-Language. Jag ställer in q-värden för mediatyper så att moderna format prioriteras, till exempel image/webp före image/jpeg. Jag ser alltid till att ställa in Vary korrekt och leverera 406 om klienter begär ett format som inte stöds. Detta gör beteendet förutsägbart och förhindrar att cacher lagrar motstridiga svar.

# .htaccess
Alternativ +MultiViews

# Exempel för typmappning (file.var)
URI: bild
Innehållstyp: image/webp; qs=0.9
Innehållstyp: image/jpeg; qs=0.8
Innehållsspråk: de

# Automatisk drift av språkvariant
#-filer: index.html.de, index.html.en

Nginx: karta, Lua och kantlogik

Under Nginx ställer jag ofta in karta-direktiv för att utvärdera Accept-rubriker och tilldela lämpliga slutpunkter. För API:er omdirigerar jag mellan HTML och JSON beroende på Accept, eventuellt kompletterat med Lua för finare regler. Jag håller ett öga på Vary-rubriken, eftersom cacher måste koppla beslut till Accept och Accept-Language. I distribuerade konfigurationer flyttar jag delar av förhandlingen till edge-noder för att minimera latensen. En vitlista är fortfarande viktig så att jag bara erbjuder verifierade mediatyper och inte faller för exotiska format.

# nginx.conf (utdrag)
map $http_accept $fmt {
  standard "html";
  "~*application/json" "json";
  "~*\\*/\\\*" "json";
}

server {
  add_header Vary "Accept, Accept-språk";
  plats /api {
    try_files $uri $uri/ /api.$fmt;
  }
}

Caching, Vary och SEO-signaler

Utan korrekt Varierande-rubriker beter sig cacher oförutsägbart och levererar felaktiga varianter till andra användare. Jag ställer in Vary exakt till de rubriker som jag använder för att differentiera, dvs. vanligtvis Accept, Accept-Language och Accept-Encoding. Detta stärker inte bara konsekvensen, utan sänder också tydliga signaler om prestanda, vilket indirekt ger SEO-fördelar. De som vill fördjupa sig i header-strategier kommer att ha nytta av den här guiden till HTTP-rubriker för prestanda och SEO. Jag kontrollerar också om CDN-cache-nyckeln mappar dessa dimensioner så att edge-noderna innehåller rätt objekt.

API:er: Vitlistning av format och ren fallback

Med API:er håller jag de mediatyper som stöds i en Whitelist till exempel application/json och application/xml. Om Accept-headern saknas eller om inget passar in anger jag JSON som standard, eftersom det är det format som stöds mest. Om en klient uttryckligen begär ett okänt format svarar jag med 406 Not Acceptable i stället för att gissa i tysthet. En användares profilinställningar har företräde framför Accept om applikationen anger detta. Jag ser till att dessa regler är centraliserade, reproducerbara och validerade med hjälp av tester så att integrationerna förblir stabila.

Språk, typsnitt och tillgänglighet

För Flerspråkighet Jag använder Accept-Language för att automatiskt välja språkvarianter och markera Content-Language i svaret. Jag formulerar fallbacks tydligt: om det önskade språket inte finns, använder jag ett definierat standardspråk. Jag använder Accept-Charset för att se till att UTF-8 gäller överallt så att specialtecken visas konsekvent. Skärmläsare har också nytta av korrekta språknamn i innehållets språk och lang-attribut i markeringen. På så sätt blir leveransen inkluderande, transparent och tekniskt ren.

Bilder, komprimering och medietyper

När det gäller bilder ger jag moderna format en Projektion och var uppmärksam på webbläsarnas Accept-rubriker. Om klienten stöder AVIF eller WebP föredrar jag att leverera dessa versioner, annars väljer jag JPEG eller PNG. Den här praktiska guiden hjälper mig att välja mellan WebP och AVIF Jämförelse mellan WebP och AVIF. Jag minskar också datamängden avsevärt genom att använda acceptkodning med Brotli eller Gzip, ofta upp till 50 % i praktiken. Detta sparar bandbredd, förkortar tiden till första byte och stabiliserar den upplevda hastigheten.

Mät, testa, rulla ut

Jag mäter effekten av förhandlingen löpande, annars kvarstår potential oanvänd. Jag använder curl för att kontrollera varianter, till exempel curl -H „Accept: application/json“ eller curl -H „Accept-Language: de“. Jag kontrollerar träfffrekvenser per variant i loggar och jämför dem med CDN-statistik. För kodningsstrategier och Brotli-grader jämför jag resultatkurvor innan jag ställer in globala standardvärden. Den här guiden till installation och inställning ger mig en kompakt introduktion till Konfigurera HTTP-komprimering, som jag samordnar parallellt med förhandlingen.

Felkoder och gränsfall i praktiken

Jag gör en tydlig åtskillnad mellan 406 Not Acceptable och 415 Unsupported Media Type: Jag anger 406 om Svar inte är tillgänglig i en accepterad variant (Accept denied); jag använder 415 om Förfrågan skickar en medietyp som inte stöds (innehållstyp i begärans nyttolast). I sällsynta fall är 300 Multiple Choices meningsfullt om jag vill erbjuda klienten flera exakt matchande varianter - i praktiken använder jag dock tydliga standardvärden istället för interaktivt urval i miljöer med hög belastning. För cachelagring fortsätter jag att svara med 304 Not Modified per variant; ETag och Last-Modified gäller alltid variantspecifikt. Om Accept saknas helt tolkar jag det som att „allt är tillåtet“ och använder det definierade standardvärdet (vanligtvis JSON för API:er, HTML för webbplatser). Om en klient anger q=0 för en typ, utesluter jag uttryckligen denna variant.

Säkerhet: sniffning, vitlistor och input-hygien

Jag låter inte webbläsaren „gissa“ innehållstypen, utan ligger med konsekvent innehållstyp och X-Content-Type-Options: nosniff fixad. I förhandlingslogiken accepterar jag bara typer/språk på vitlistan och begränsar längden på rubrikerna så att ovanligt långa listor över accepterade språk inte binder upp resurser. För loggar och mätvärden rensar jag upp rubrikvärden för att undvika injektionsrisker. Jag är också uppmärksam på dataskydd: Accept-språk kan göra det möjligt att dra slutsatser om användare; jag sparar bara så mycket som är nödvändigt och aggregerar för statistik. Med CORS låter jag förhandlingen bestämma självständigt - jag binder cross-origin-regler separat till Origin/Methods/Headers, inte till Accept-varianter, så att jag inte genererar några oavsiktliga auktoriseringar.

CDN, cache-nycklar och ETags per variant

Med CDN:er definierar jag medvetet cache-nyckeln som variabel. Förutom URL inkluderar detta Accept, Accept-Language och Accept-Encoding, precis som jag signalerar i Vary-headern. Jag ställer in mina egna ETags för varje variant (t.ex. hash med suffix „.json.de.br“) och ser till att villkorliga förfrågningar fungerar korrekt. För statiska tillgångar arbetar jag med förgenererade, komprimerade filer (br/gz) som CDN:t serverar 1:1. För att minska ursprungsbelastningen använder jag „collapsed forwarding“ eller „stale-while-revalidate“: Den första missen uppdateras, alla andra får en ny eller „stale acceptable“-variant. Jag kombinerar endast räckviddsförfrågningar med komprimering om servern och CDN hanterar funktionen konsekvent; annars avaktiverar jag räckvidden för dynamiskt komprimerade svar för att undvika fragmentering av varianterna.

q-värden, jokertecken och matchningsalgoritm

Om flera varianter gäller sorterar jag efter q-värden och precision: exakt typ/subtyp slår typ/*, båda slår */*. Om q är detsamma vinner den mer specifika varianten. Om kunden inte anger något q-värde tolkar jag det som 1,0. Med q=0 utesluter kunden uttryckligen en typ. För bilder och dokument föredrar jag moderna format med ett något högre q, men erbjuder fallbacks om kunden t.ex. inte känner igen AVIF.

# Pseudokod för matchning av accept
parsa acceptHeader till kandidater (typ, subtyp, q)
för variant i serverVariants:
  poäng = 0
  för cand i kandidater:
    if cand.type == variant.type och cand.subtype == variant.subtype:
      score = max(score, 1000 * cand.q + 2) # exakt
    elif cand.type == variant.type och cand.subtype == "*":
      score = max(score, 1000 * cand.q + 1) # typ/*
    elif cand.type == "*" och cand.subtype == "*":
      poäng = max(poäng, 1000 * cand.q) # */*
  tilldela bästa poäng
välj variant med högsta poäng eller 406 om alla poäng är 0

Jag går tillväga på ett liknande sätt med Accept-Language: „de-CH“ prioriterar „de-CH“ framför „de“, först därefter faller valet på den globala standarden. Jag håller urvalet deterministiskt så att cacher lagrar tillförlitliga objekt.

Exempel på ramverk: Express/Node och Go

I applikationsramverk kapslar jag in reglerna i middleware, ställer in Vary konsekvent och håller fallbacks centraliserade.

// 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 (förenklat)
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 }
  returnera false
}

func handler(w http.ResponseWriter, r *http.Request) {
  w.Header().Add("Vary","Accept, Accept-Språk, Accept-Kodning")

  if !negotiateJSON(r) {
    w.WriteHeader(http.StatusNotAcceptable)
    w.Write([]byte("Inte acceptabelt"))
    return
  }
  w.Header().Set("Content-Type", "application/json; charset=utf-8")
  io.WriteString(w, `{"ok":true}`)
}

Det är viktigt att jag aldrig förlitar mig på User-Agent, utan endast på uttryckliga Accept*-rubriker. Detta gör beteendet reproducerbart och testbart.

Internationalisering i detalj

Jag upprättar en tydlig fallback-kedja, t.ex. de-CH → de-DE → de → Default. Om det inte finns någon regionkod bryter jag ner den till basspråket. I svaret använder jag Content-Language för att ange exakt den valda varianten och undvika blandformer. Användarinställningar (t.ex. kontolokal) har företräde framför Accept-Language, men mappas också på ett deterministiskt sätt till språk som systemet faktiskt tillhandahåller. Av SEO- och tillgänglighetsskäl ser jag till att lang-attributen i HTML och innehållsspråket är konsekventa; jag förhindrar också omdirigeringsslingor genom att fatta beslutet på serversidan och instruera cacheminnet korrekt via Vary.

Rena kanoniseringar av request-drivna varianter

Om jag kombinerar URL-parametrar (t.ex. ?format=json) med Accept behöver sidan en tydlig kanonisering: antingen accepterar jag parametern som en hård standard och ignorerar Accept, eller så är parametern bara en ledtråd som kan åsidosättas av Accept. Jag dokumenterar regeln tydligt och anger konsekventa rubriker i svaret så att cacheminnet inte lagrar två olika representationer av samma URL utan en åtskiljande Vary-nyckel. För HTML-sidor säkerställer jag också en unik kanonisk adress per språk-/formatvariant inom systemet så att analyser och övervakning inte räknar dubbletter.

Finjustera och förproducera komprimering

För dynamiska svar balanserar jag CPU-kostnaderna för komprimering mot nätverksbesparingarna. Brotli på nivå 4-6 ger vanligtvis ett bra förhållande; högre nivåer är särskilt värdefulla för statiska tillgångar som jag komprimerar i förväg. Jag har både br och gzip till hands för stora filer eftersom inte alla klienter stöder Brotli. I praktiken sparar jag förkomprimeringarna med filtillägg (.br/.gz), låter servern bestämma baserat på tröskelvärden för acceptkodning och filstorlek och ställer in innehållskodning korrekt. Viktigt: Varje komprimerad variant får sin egen ETag; annars kommer villkorliga förfrågningar att leverera felaktiga 304-svar.

Observerbarhet, canary och rollback

Jag inför förhandlingsregler med funktionsflaggor, aktiverar dem steg för steg (t.ex. 5 %, 25 %, 100 %) och övervakar nyckeltal för varje variant: felfrekvens, latens, byte ut, cache-träfffrekvens, andel 406/415. Jag noterar den valda varianten och de utlösande rubrikerna (aggregerade) i loggarna så att jag snabbt kan hitta avvikelser. För tester använder jag syntetiska testare som regelbundet kör kända acceptkombinationer mot staging och produktion. I händelse av avvikelser rullar jag specifikt tillbaka varianter utan att stoppa hela systemet - till exempel genom att tillfälligt avaktivera AVIF, tvinga JSON som standard eller minska Vary-dimensionen tills cacheminnet återhämtar sig.

Sammanfattning : Rätt svarsformat lönar sig

Jag levererar snabbare, sparar Bandbredd och öka tillfredsställelsen om jag använder innehållsförhandling konsekvent. Kombinationen av Accept-rubriker, tydliga fallbacks, q-värden och Vary garanterar stabila och reproducerbara svar. I praktiken prioriterar jag serverstyrda beslut, håller cacher variantkapabla och testar varje regel med curl. API:er får en strikt vitlista, webbplatser drar nytta av språk- och bildvarianter samt modern komprimering. På så sätt uppnår projektet mätbara fördelar när det gäller prestanda, tillgänglighet och underhållbarhet - med en installation som jag kontrollerar på ett målinriktat sätt och kan spåra när som helst.