Innehållsförhandling
HTTP |
---|
Begär metoder |
Rubrikfält |
Svarsstatuskoder |
Säkerhetsåtkomstkontrollmetoder |
Säkerhetssårbarheter |
Innehållsförhandling avser mekanismer definierade som en del av HTTP som gör det möjligt att servera olika versioner av ett dokument (eller mer allmänt representationer av en resurs) på samma URI , så att användaragenter kan specificera vilken version som passar deras kapacitet bäst . En klassisk användning av denna mekanism är att visa en bild i GIF- eller PNG- format, så att en webbläsare som inte kan visa PNG-bilder (t.ex. MS Internet Explorer 4) kommer att få GIF-versionen.
En resurs kan finnas tillgänglig i flera olika representationer; den kan till exempel vara tillgänglig på olika språk eller olika mediatyper. Ett sätt att välja det lämpligaste valet är att ge användaren en indexsida och låta dem välja det lämpligaste valet; men det är ofta möjligt att automatisera valet baserat på vissa urvalskriterier.
Mekanismer
HTTP tillhandahåller flera olika innehållsförhandlingsmekanismer inklusive: serverdrivna (eller proaktiva), agentdrivna (eller reaktiva), transparenta och/eller hybridkombinationer därav.
Serverdriven
Serverdriven eller proaktiv innehållsförhandling utförs av algoritmer på servern som väljer bland möjliga variantrepresentationer. Detta utförs vanligtvis baserat på acceptanskriterier som tillhandahålls av användaragenter.
För att sammanfatta hur detta fungerar, när en användaragent skickar en begäran till en server, informerar användaragenten servern om vilka mediatyper eller andra aspekter av innehållspresentation den förstår med betyg om hur väl den förstår dem. Mer exakt tillhandahåller användaragenten HTTP-rubriker som listar acceptabla aspekter av resursen och kvalitetsfaktorer för dem. Servern kan då tillhandahålla den version av resursen som bäst passar användaragentens behov.
Till exempel kan en webbläsare indikera att den vill ha information på tyska genom att ställa in Accept-Language
så här:
Acceptera-språk: de
Webbläsaren kan istället säga att tyska är att föredra, om möjligt, men att engelska också är acceptabelt genom att ställa in:
Acceptera-språk: de; q=1,0, en; q=0,5
Där 'q' - kvalitetsfaktorn för tyska är högre än den för engelska.
Flera HTTP-rubriker levereras ofta tillsammans för innehållsformat eller, specifikt mediatyp, språk och några andra aspekter av en resurs. Utöver det vanligaste Accept-
huvudet för Media Type, Accept-Language-
huvudet för språkförhandling, beskriver RFC 7231 även Accept-Charset
& Accept-Encodings
för teckenkodningar respektive innehållskodningar (komprimering).
Ett exempel på en mer komplex begäran är där en webbläsare skickar rubriker om språk som anger att tyska är att föredra men att engelska är acceptabelt, som ovan, och att HTML (text/html) föredras framför andra texttyper (text/* ) vad gäller
format .
), GIF ( image/gif
) eller JPEG ( image/jpg
) bilder föredras framför andra bildformat ( image/*
) men att alla andra mediatyper ( */*
) accepteras som en sista utväg:
Acceptera-språk: de; q=1,0, en; q=0.5 Acceptera: text/html; q=1,0, text/*; q=0,8, bild/gif; q=0,6, bild/jpeg; q=0,6, bild/*; q=0,5, */*; q=0,1
Förutom aspekter av serverdriven innehållsförhandling efter innehållstyp och språk som anges i RFC 7231, finns det tillägg som definierar andra aspekter av innehållsförhandling, såsom Memento som beskriver användningen av en Accept-Datetime
-huvud för att hämta version av en resurs representation vid speciella tidpunkter och IETF/W3C:s innehållsförhandling genom profil som beskriver användningen av en Accept-Profile
header för att hämta resursrepresentationer som överensstämmer med dataprofiler.
Varken RFC 7231 eller de nyare relaterade specifikationerna som Content Negotiation by Profile anger hur man ska lösa avvägningar i fall där olika rubriker anger motstridiga krav, som i exemplet ovan att välja mellan en HTML-sida på engelska och en GIF-bild på tyska.
Agentdriven
Agentdriven eller reaktiv innehållsförhandling utförs av algoritmer i användaragenten som väljer bland möjliga variantrepresentationer. Detta utförs vanligtvis baserat på en server tillhandahållen lista med representationer och metadata om dem.
För att sammanfatta hur detta fungerar, när en användaragent skickar en förfrågan till en server, informerar servern användaragenten om vilka representationer den har tillgängliga samt alla metadata den har om varje representation (t.ex. innehållstyp, kvalitet, språk, etc.). User-agenten skickar sedan om begäran till en specifik URL för den valda representationen. Detta kan väljas automatiskt av användaragenten eller så kan användaragenten presentera valen för användaren och användaren kan direkt välja sådana. Mer exakt svarar servern med antingen 300 Multiple Choices eller 406 Not Acceptable (när serverdrivna, acceptanskriterier för användaragent tillhandahålls men servern kan inte automatiskt göra ett val). Tyvärr lämnar HTTP formatet för listan över representationer och metadata tillsammans med urvalsmekanismer ospecificerade.
externa länkar
- RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantik och innehåll – ( Avsnitt 5.3: Innehållsförhandling )
- RFC 2295 — Transparent Content Negotiation i HTTP
- RFC 2296 — HTTP Remote Variant Selection Algoritm — RVSA/1.0
- Apache-innehållsförhandling
- PHP-innehållsförhandlingsbibliotek med öppen källkod (stöder jokertecken och q-värden)
- Diskussion om XHTML-servering med innehållsförhandling och webbläsarproblem som kräver detta
- Den här artikeln är delvis baserad på den här sidan , som är upphovsrättsskyddad av Apache Foundation men släppt under en fri licens.