De flesta av oss kanske inte funderar så mycket över vad det där "http:" som är med i alla webbadresser egentligen innebär.
Men sätter man sig bara in i ämnet HTTP helt översiktligt ("HyperText Transfer Protocol" - alltså reglerna för hur man överför webbsidor rent tekniskt) - så ser man att det automatiskt skickas med en hel del information man kan ha nytta av varje gång en webbsida överförs...
Vi pratar alltså om den "HTTP-Header" som överförs mellan en webbläsare och din webbserver varje gång en webbsida begärs och den nytta man kan ha av innehållet i den.
Serverns HTTP-header
De flesta av oss har redan kommit i kontakt med informatonen i den HTTP-header som vår webbserver bifogar våra webbsidor genom att vi regelmässigt använder vissa metataggar, t.ex.
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />Det har alltså blivit lite vardagsmat för de flesta av oss att webbservern skickar med en "header" med en webbsida varje gång den överförs och att vi kan påverka vissa inställningar för sidan med "meta http-equiv"...
Det som inte är vardagsmat, är kanske att inse att det vi egentligen gör är att påverka HTTP-protokollet direkt (ja - iallafall om webbservern vi använder är inställd på att tolka metataggar "on the fly"! - men mer om de detaljerna kommer i en senare artikel)
För den nyfikne finns det flera verktyg på nätet för att kolla vad en webbserver lämnar ifrån sig för "huvudinformation".
T.ex. kan du se hur huvudet ser ut för alla sidor på den här webbplatsen via denna länk till en webbtjänst på svanstrom.nu med hjälp av Web Developers Toolbar-tillägget för Mozilla eller liknande.
Så långt servern... Men även en webbläsare skickar med en header som man kan ha nytta av...
Vad en webbläsare egentligen vill ha...
Hej jag är [webbläsaren x] och jag kan hantera [det här] - var snäll och ge mig [sidan som har den här adressen], och förresten här är [några cookies] som du lagrade hos mig senast jag var på besök.
Ja ungefär så kan man sammanfatta hur en webbläsare begär en webbsida av din webbserver.
Syftet med informationen är förstås att ge webbservern möjlighet att anpassa innehållet och kodningsformatet på den webbsida som begärs efter vad webbläsaren som begär sidan kan klara av...
Det mesta som ingår i headern loggas automatiskt i webbserverns logg - t.ex. brukar besökarens IP-adress, "User-agent" (webbläsarsignatur), Referrer (dvs sidan som besökaren kom ifrån) m.fl fält hamna i loggen
Men inte alla fält man kan ha nytta av hamnar där automatiskt - och därför kan det vara lätt att bortse ifrån den nytta man kan ha av dem!
User_Agent
Detta är den s.k. "webbläsarsignaturen" som några av oss antagligen redan stött på vid någon "Browser sniffing", och den här brukar hamna i webbserverloggarna automatiskt.
Ja - ni vet - om det står "MSIE" någonstans i "User_Agent" så är detta en Explorer...
Exempel på en "User_Agent"-sträng för MSIE6:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; .NET CLR 1.0.3705)och för en Mozilla
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826Denna information brukar användas när man bygger webbplatser som måste kunna skicka olika kodade webbsidor till olika webbläsare.
Principen för valet bygger på att strängens format är relativt standardiserad för alla "kända" webbläsare
Nackdelen med de "browser sniffers" som finns brukar vara att de inte kan hantera "okända" webbläsare (t.ex. splitternya) och att det trots alla goda intentioner lätt ändå lätt blir fel i samband med att besökare med ovanliga webbläsare dyker in
En annan aspekt av att använda sig av analys av "User_Agent"-strängen, är att det i t.ex. Opera numera ganska enkelt går att välja olika inställningar på denna så att den kan "låtsas" vara en IE6:a eller en Mozilla...
Analys av "User_agent" blir alltså sällan helt hundraprocentigt pålitlig...
Speciellt inte om man är ute efter att servera antingen "text/html" eller "application/xhtml+xml" beroende på vad man tror att webbläsaren klarar av...
Är man sedan dessutom ute efter att även kunna servera WAP-sidor (eller "xhtml Mobile Profile"-sidor) till de nallefoner som kan hantera dessa så blir listan på vilka "User_Agents" man måste känna till inte speciellt mycket kortare ;) ...
Att bara söka efter "User_Agent"-strängar som innehåller "Nokia" eller "Ericsson" räcker inte långt i dessa tider när nallefoner börjar innehålla Opera-webbläsare och nallefoner börjat säljas under märket "Vodaphone" ... ;)
Men det finns ett fält i headern som man kan ta till för att komma förbi det problemet... (även om det inte brukar dyka upp i loggarna normalt)
Accept
Detta fält innehåller en lista på vilka format webbläsaren klarar av att hantera
Greit! - här borde det alltså stå "text/html", "application/xhtml+xml" och "text/vnd.wap.wml" då - eller?
Njae - låt oss titta på vad MSIE6 anger att den klarar av:
image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, application/x-shockwave-flash, */*Hmm... Nästan bara Microsoft-specifika MIME-typer... Och så */* på slutet (vilket betyder "vad som helst - jag klarar precis ALLT") Vilket vi ju vid det här laget vet är en liten överdrift... Inte mycket hjälp där alltså!
Men vänta - Mozilla då?
text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,
image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1Ja SÅ skall det se ut ja!
Inte nog med att den radar upp alla den klarar av (med kommatecken emellan) - den anger också vilka den föredrar... Låt se hur det går till
Lägg märke till att t.ex. "text/html" åtföljs av ";q=0.9" och att "text/plain" åtfäljs av ";q=0.8" samtidigt som t.ex. "application/xhtml+xml" inte har någon "q-faktor" alls efter sig...(OBS! semikolon som separator framför alla q-värden och, som sagt, komma emellan MIME-typerna!)
Det betyder att om Mozilla får välja, så tar den helst emot "application/xhtml+xml" (eller "text/xml" osv som också saknar Q-faktor) och därefter, om inte dessa finns, hellre "text/html" än "text/plain" (ju lägre q-värde, destå mindre "gärna" vill den ha formaten)...
Mozilla anger också - till sist - att om inget annat finns, så kan den väl prova "*/*"-då (q=0.1 på den!)...
Hmm... Det här skulle man ju kunna använda om alla webbläsare var noga med att begära de format de är byggda för...
Opera då? - hur ser det ut för Opera? och Lynx? eller Konqueror? Eller Chimera?
Ja Opera 6 och Lynx kan jag testa - de kommer här (i ordning):
text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*text/html, text/plain, text/sgml, */*;q=0.01Men vad har det här med xhtml att göra nu då?
Jo om man ser lite mönster i det här så antydde jag i artikeln om fem olika sätt att skriva ett xhtml-dokument att webben inte riktigt är mogen för xhtml-sidor som serveras som W3C rekommenderar (som "application/xhtml+xml").
Det påståendet bygger på antagandet att det är svårt att veta exakt vilka versioner av vilka webbläsare som är mogna för detta...
Men om man nu kan tänka sig att leverera en bakåtkompatibel "vanilj"-xhtml-sida till alla de som bara klarar "text/html" (dvs ALLA som inte explicit begär något "bättre" om vi pratar webbsidor) och en xhtml-sida som utnyttjar alla de finesser som finns i xhtml- och CSS-standarderna serverad som "application/xhtml+xml" till de webläsare som tagit steget fullt ut och begär "application/xhtml+xml" då?
Just det! - där har du den goda kärnan i den här idén...
Och sen då??
I nästa artikel i det här ämnet skall vi se hur man kan konfigurera Apache till att hantera den här typen av "content negotiation" automatiskt.
