406 Not Acceptable: Hva det betyr, hvorfor det oppstår og hvordan du løser det

by Nettredaktor Soek og ytelse
Pre

406 Not Acceptable er en av de mindre kjente, men viktige HTTP-statuskodene som gir mening for utviklere, API-integratorer og nettlesere når innhold ikke kan negotiates mellom klient og server. I praksis handler det om innholdssforhandling (content negotiation) og hvilke formater en klient aksepterer, og hva serveren kan levere. Dette er ikke bare en teknisk nyanse; det påvirker brukeropplevelse, API-design og feilsøkingsrutiner ved feil i kommunikasjonen mellom klient og server.

Hva betyr 406 Not Acceptable?

406 Not Acceptable betyr bokstavelig talt at forespørselen fra klienten ikke kunne tilfredsstilles av serveren gitt det som ble bedt om via Accept-headeren og andre relaterte preferanser. Hvis en klient for eksempel ber om JSON, XML eller HTML, og serveren kun kan levere et format som ikke samsvarer med disse preferansene, kan serveren svare med 406 Not Acceptable.

Det er viktig å merke seg at dette er forskjellig fra andre 4xx-feilkoder som 404 Not Found eller 403 Forbidden. I hovedsak er 406 en indikasjon på at innholdet i responsen kunne vært tilpasset forskjellige formater, men serveren har ikke mulighet til å gjøre det gitt forespørselen. I stedet for å returnere noe annet standardinnhold, svarer serveren med 406 for å signalisere at klientens krav til innholdstype ikke er oppfylt.

Content negotiation: Hvordan fungerer det?

Content negotiation er mekanismen hvor klient og server forhandler frem hvilket innhold som skal leveres. Dette skjer ofte gjennom Accept-, Accept-Language-, Accept-Charset- og Accept-Encoding-headere i HTTP-forespørselen. Nøkkelideen er at klienten sier: “Jeg vil ha data i dette formatet, på dette språket og med denne koding, hvis mulig.”

Accept-headeren og formater

Accept-headeren forteller serveren hvilke medietyper klienten foretrekker. For eksempel:

  • Accept: application/json
  • Accept: text/html
  • Accept: application/xml
  • Accept: */*

En server som ikke kan levere noen av de ønskede formatene, kan returnere 406 Not Acceptable. Noen ganger er det også mulig at serveren kan levere et annet format, men det kan være riktig å samtidig angå 406 Not Acceptable dersom alternativene ikke faktisk samsvarer med forespørselen.

Accept-Language og andre preferanser

Accept-Language angir foretrukket språk for innhold. Accept-Encoding lar klienten spesifisere kompresjonsformer (som gzip). Accept-Charset er mindre vanlig i REST-APIer, men i historiske applikasjoner kan dette også påvirke muligheten for å levere riktig innhold.

Når oppstår 406 Not Acceptable?

406 Not Acceptable oppstår ofte i følgende scenarier:

  • En API eller nettside tilbyr innhold i få spesifikke formater (for eksempel JSON eller XML), mens klienten ber om et annet format via Accept-headeren.
  • En innhold- eller tjeneste som ikke støtter det språket eller encoding som klienten forespør.
  • En riktig konfigurert server som ikke har en gyldig fallback-innstilling hvis preferansene ikke kan tilfredsstilles.

Forskjeller mellom 406 Not Acceptable og andre vanlige koder

Å skille mellom ulike 4xx-feilkoder kan være utfordrende, men det er viktig for riktig feilsøking.

406 Not Acceptable vs. 404 Not Found

404 Not Found betyr at ressursen ikke finnes i det hele tatt. 406 Not Acceptable betyr derimot at ressursen finnes, men inneholdet kan ikke leveres i det formatet klienten har bedt om.

406 Not Acceptable vs. 415 Unsupported Media Type

415 Unsupported Media Type indikerer at serveren ikke kan behandle innholdet i forespørselen fordi medietypen som ble sendt i forespørselen er feil (vanligvis i POST/PUT-forespørsler). 406 Not Acceptable gjelder derimot responsformatet og innholdskonfigurasjoner, ikke nødvendigvis innholdet i forespørselen.

406 Not Acceptable vs. 400 Bad Request

400 Bad Request er en generell indikasjon på at forespørselen er syntaktisk feil eller mangler obligatoriske data. 406 Not Acceptable er en spesifikk feil knyttet til innholdstyper og tilgjengelige representasjoner.

Praktiske eksempler og scenarier

Å forstå praktiske scenarier hjelper med å sette 406 Not Acceptable i kontekst:

Eksempel 1: En API som kun støtter JSON

Klienten sender en forespørsel til en API med Accept: application/xml, men serveren kan kun returnere JSON. Serveren kan svare 406 Not Acceptable for å indikere at XML ikke er tilgjengelig.

Eksempel 2: Flere representasjoner, men ingen som passer

En tjeneste tilbyr både JSON og CSV, men klienten ber kun om en ukjent eller støttet representasjon via Accept. Da kan serveren svare 406 Not Acceptable eller gi en annen oppsett som ikke tilfredsstiller klients ønsker.

Eksempel 3: Språkforhandling

Klienten ber om innhold på norsk (Accept-Language: no) men ressursen er kun tilgjengelig på engelsk. Hvis serveren ikke har passende oversettelser, kan 406 Not Acceptable være en løsning for å signalisere at språket ikke kan tilfredsstilles.

Hvordan bruke 406 Not Acceptable i API-design og dokumentasjon

Gode API-praksiser hjelper utviklere å unngå unødvendige 406-oppkall og forbedre utvikleropplevelsen.

Klare krav i dokumentasjonen

Dokumentasjonen bør tydeliggjøre hvilke representasjoner som støttes for hver endepunkt, og hvilke Accept-headers som er ønsket. Hvis det ikke er mulig å levere visse representasjoner, bør dokumentasjonen foreslå alternative aksepterte formater eller fallback-metoder.

Angi tilgjengelige alternativer som standard

Hvis serveren har begrensede alternativer, kan den sette en standard representasjon og tydelig kommunisere dette i dokumentasjonen eller i 406-svaret ved behov. Det gir utvikleren en klar forventning og reduserer unødvendige feil.

Hvordan debugge 406 Not Acceptable som utvikler

Feilsøking av 406 Not Acceptable handler om å avdekke hvor Accept-header eller preferansene ikke samsvarer med serverens tilbud. Følg disse trinnene:

  1. Kontroller Accept-headeren i forespørselen. Prøv bredere aksepterte formater som Accept: */* for å teste om serveren har et tilgjengelig format.
  2. Test med kursingverktøy (curl) for å se hvilke formater som blir levert. Eksempel: curl -i -H “Accept: application/json” https://example.com/resource
  3. Undersøk serverloggene for detaljer om begrunnelsen til 406-svaret. Se etter hvilke representasjoner serveren tilbyr.
  4. Prøv å spesifisere Accept-Headeren eksplisitt til et format som er kjent å være tilgjengelig, for eksempel Accept: application/json eller Accept: text/html.
  5. Hvis du har kontroll over serverkonfigurasjon, vurder fallback-mekanismer eller eksplicitte 406-sider som gir nyttig feilmelding til klienter.

Hvordan løse 406 Not Acceptable på klientsiden

Klienter opplever ofte 406 Not Acceptable fordi forespørslene er begrenset til for snevre preferanser. Her er noen praktiske løsninger:

Justere Accept-headeren

Åpne dokumentasjonen for APIet og identifiser hvilke formater som støttes. Endre Accept-headeren til et av de støttede formatene, for eksempel:

GET /resource HTTP/1.1
Host: api.example.com
Accept: application/json

Bruke wildcard eller flere alternativer

Hvis serveren støtter flere representasjoner, kan du bruke Accept: application/json, application/xml for å be om en av disse. Noen klientsider støtter også Accept: */* som en bred søknad om hvilket som helst format.

Fornye forespørsel med riktig språk

Hvis feilen er språkrelatert, sørg for at Accept-Language angir språkklassen som er støttet av serveren, for eksempel Accept-Language: no-NO eller Accept-Language: no.

Hvordan løse 406 Not Acceptable på serversiden

Servere bør være tydelige, robuste og forutseende når de møter 406 Not Acceptable. Dette innebærer riktig konfigurasjon og forståelse av hva klientene forventer.

Nginx-eksempel

En enkel løsning er å tilby en standard representasjon og respondere med 406 hvis ingen aksepterte representasjoner er tilgjengelige. Generell konfigurasjon innebærer ofte å omdirigere til en spesifikk feilside eller å tilby en fallback-ressurs.

server {
  listen 80;
  server_name example.com;

  location /resource {
    try_files $uri $uri/ =404;
  }

  error_page 406 = /406.html;
  location = /406.html {
    root /var/www/html;
  }
}

Apache-eksempel

Apache-nettserveren kan settes opp til å sende en spesifikk feilmelding når innhold ikke tilfredsstiller Accept-headers. Dette kan gjøres med en tilpasset errordocument.


  ServerName example.com
  DocumentRoot /var/www/html

  
    Options -MultiViews
  

  ErrorDocument 406 /406.html

Node.js og Express

Ved API-er bygget i Node.js kan du eksplisitt håndtere scenarioet og sende 406 Not Acceptable når representasjoner ikke er tilgjengelige.

app.get('/resource', (req, res) => {
  const acceptsJson = req.accepts('json');
  const acceptsHtml = req.accepts('html');

  if (acceptsJson) {
    res.json({ data: 'JSON representation' });
  } else if (acceptsHtml) {
    res.send('HTML representation');
  } else {
    res.status(406).send('Not Acceptable');
  }
});

Django og andre rammeverk

I Django og andre rammeverk kan du implementere et filter i view-funksjonen eller middleware som analyserer Accept-header og avgjør om det er mulig å levere et passende svar, ellers returneres 406 Not Acceptable.

Best praksis for å unngå unødvendige 406 Not Acceptable-feil

Selv om 406 Not Acceptable er en legitim HTTP-status, er det ofte bedre å designe APIer og applikasjoner slik at klienter ikke må gjette feil formater:

  • Tilby klare og tydelige dokumentasjonskrav til representasjoner som støttes av endpointene.
  • Tilby en default-representasjon dersom klienten ikke spesifiserer Accept-header eksplisitt.
  • Bruk versjonering i API-et for å unngå brå endringer i tilbudte representasjoner.
  • Inkluder informative feilmeldinger i 406-responsen som gir klienten hint om tilgjengelige alternativer.

Relaterte feilkoder og nyttige forskjeller

Noen ganger kan det være nyttig å sammenligne 406 Not Acceptable med lignende statuskoder for å få bedre kontekst:

406 Not Acceptable vs. 300 Multiple Choices

300 er en indeksering som indikerer at ressursen har flere representasjoner tilgjengelig og klienten bør velge en via lenker. 406 Lettere signaliserer at klientens preferanser ikke kan møtes, ikke at valgene er tilgjengelige.

406 Not Acceptable vs. 304 Not Modified

304 brukes i cache-sammenhenger for å indikere at klientens lokale kopier er oppdaterte. 406 er ikke en caching-relatert melding, men en spørsmål om innhold og format.

Ofte stilte spørsmål om 406 Not Acceptable

Her er svar på noen av de vanligste spørsmålene knyttet til 406 Not Acceptable:

Kan en nettleser vise 406 Not Acceptable for vanlige nettsider?

Ja, spesielt hvis en nettside eller tjeneste forsøker å levere innhold i et format som ikke støttes av nettleseren eller som serveren ikke kan konvertere til for øyeblikket.

Er 406 Not Acceptable det samme som 415?

Nei. 415 handler om at innholdstypen (medietypen) som ble sendt i forespørselen ikke kan håndteres av serveren. 406 gjelder innholdets representasjoner og hva som kan leveres som respons basert på Accept-headers.

Kan 406 Not Acceptable være midlertidig?

Ja, hvis serverens tilbudte representasjoner midlertidig er begrenset eller hvis klienten endrer Accept-header og dermed nå er innenfor tilbudet. Langsiktig løsning er å sikre at serveren tilbyr minst én gyldig representasjon som dekker de mest vanlige forespørslene.

Oppsummering: Hva bør du ta med deg om 406 Not Acceptable

406 Not Acceptable er en signaliserende HTTP-status som forteller oss at innholdet som klienten ber om ikke kan leveres i de tilgjengelige representasjonene. For utviklere er det viktig å ha en klar forståelse av content negotiation og hvordan Accept-headeren påvirker hva som leveres. For API-eiere og team som designer webapplikasjoner, er det lurt å dokumentere støtte for representasjoner tydelig, sette klare fallback-mekanismer og gi informative feilmeldinger når 406 Not Acceptable blir brukt. På klient-siden gjelder det å justere Accept-headers, teste forskjellige formater og sørge for at språk og encoding stemmer overens med serverens tilbud.

Avslutning

I en verden av varierte klienter og mange ulike datarepresentasjoner, er 406 Not Acceptable en trygg og forutseende måte å kommunisere om innholdskrav som ikke kan oppfylles. Ved å forstå hvordan content negotiation fungerer, og ved å implementere klare praksiser både på klient- og serversiden, kan du redusere forekomsten av 406 Not Acceptable og sikre en bedre og mer pålitelig brukeropplevelse.

Ytterligere ressurser og koblinger

For de som ønsker å fordype seg i HTTP-statuskoder og content negotiation, kan følgende punkter være nyttige når du arbeider med 406 Not Acceptable i praksis:

  • Dokumentasjon av serverkonfigurasjon og hvordan den håndterer Accept-headers.
  • Verktøy for testing av Accept-headers og simulering av 406 Not Acceptable-scenarier.
  • Eksempel på API-dokumentasjon som tydelig beskriver støttede representasjoner.

406 Not Acceptable, riktig forstått, blir en verdi for å sikre at klient og server forstår hverandre når det gjelder hva slags innhold som kan leveres og i hvilket format. Ved å sette riktige forventninger og tilby tydelige løsninger, kan du gjøre kommunikasjonen mellom klienter og servere betydelig bedre og mer robust.

Praktiske kodesnutter og forespørselseksempler

Her er noen enkle eksempler som viser hvordan Accept-header påvirker respons og hvordan en riktig konfigurert klient kan håndtere 406 Not Acceptable situasjoner:

Forespørsel som indikerer JSON-foretrukket representasjon

GET /resource HTTP/1.1
Host: api.example.com
Accept: application/json

Forespørsel med flere aksepterte formater

GET /resource HTTP/1.1
Host: api.example.com
Accept: application/json, text/html;q=0.9

Test av fallback ved 406

curl -i -H "Accept: application/xml" https://api.example.com/resource

Ved å bruke slike praktiske eksempler blir det enklere å identifisere og løse problemer knyttet til 406 Not Acceptable, og å sikre at brukere får en god og forutsigbar opplevelse når de kommuniserer med tjenester på nettet.