Skapa en webbplats

Inledning

Denna bok behandlar skapande av en webbplats, i första hand med tanke på en organisation som tänker grunda en någorlunda ambitiös webbplats utan att från tidigare ha större erfarenhet av webbpublicering. Delar av den är till nytta också för personer med erfarenhet av webbutveckling eller personer som endast vill veta hur en webbplats fungerar.

Vi presenterar kort vissa aspekter av WWW och av hur en webbplats fungerar. Boken koncentrerar sig på sådant man bör tänka på då man planerar att skapa en webbplats eller då man skapar själva webbplatsen. Vi ger också en del råd om senare underhåll och om att till exempel byta från ett webbhotell till ett annat.

De tekniska sidorna behandlas endast ytligt. Att sätta upp en webbserver, att skriva enskilda webbsidor, de olika program- och märkspråk som kan behövas och vissa andra teman behandlas i andra delar av denna bok eller andra Wikiböcker.

Översikt

[Kontrollera arbetsfördelningen mellan inledning, översikt och de mer detaljerade avsnitten. Detta görs bäst då innehållets omfattning verkar känd. Inledningen borde också förenklas och göras mer lättförståelig]

Vad är en webbplats?

En webbplats kan uppfattas som en helhet bestående av ett antal webbsidor och relaterade funktioner. Definitionen är lös, men det är vanligt att en webbplats har en egen domänadress eller åtminstone ett eget filträd på en webbserver.

Domännamn, IP-adress och server

Webbplatsens adress (URL för huvudsidan) består bland annat av ett domännamn, som tolkat via domännamnssystemet (DNS) ger en IP-adress och därmed den serverdator man skall kontakta för att nå webbplatsen.

IP-adressen är en nummerserie som används för att styra datapaketen till rätt dator. För att routrarna inte skall behöva hålla reda på all världens IP-nummer delas adresserna ut blockvis. Man skall normalt få en IP-adress av den som sköter ens kontakt till övriga Internet. Kopplingen mellan domännamn och IP-adress sköts av namnservrar. Då man vill veta IP-adressen vänder man sig till namnservern som angivits av den som registrerat domännamnet och då man vill veta domännamnet vänder man sig till namnservern som angivits av den som registrerat IP-adressen. Uppgifterna borde stämma överens, men många webbhotell slarvar med detta och privatpersoner har sällan kontroll över någondera.

En dator kan betjäna flera domäner och flera IP-adresser. Webbplatsen kan alltså betjänas av en skild dator, av en så kallad virtualmaskin (som beter sig som en skild dator men i själva verket endast existerar som ett datorprogram) eller av en virtuell server (en webbserver som betjänar olika domäner beroende på under vilket namn den kontaktas).

Om man har tillräckligt säker nätkontakt och strömförsörjning kan man placera webbservern hos sig själv. Det vanliga är ändå att anlita ett webbhotell eller ett annat företag, som upprätthåller de delar av infrastrukturen och driften man inte själv har resurser för eller intresse att sköta.

Webbhotell

[Något om olika möjligheter]

Webbplatsens struktur

• Logisk, både internt och som den syns utåt
• Enligt tema, administration, språk eller målgrupp?
• ...

Planera underhållet

• Underhållet skall planeras i förväg eller också glöms det bort.
• Systematik!
• Webbplatsen kan också byggas så att den är lättare att underhålla, till exempel genom att hålla vissa delar fria från föränderligt data och koncentrera sådant som måste uppdateras genast till enstaka sidor
• ???

Domännamn

Domännamnet består av en toppdomän och underdomäner. Toppdomänen är antingen en ”nationell” domän (förkortningar på två bokstäver), såsom ”ax”, ”fi”, ”nu”, ”sv” och ”to” för Åland, Finland, Niue, Sverige respektive Tonga, eller en ”generell” domän (tre eller fler bokstäver), såsom de gamla ”com”, ”net” och ”org” (för företag, organisationer för internetinfrastruktur respektive övriga organisationer) eller nyare (och mindre väletablerade) biz, info och name. EU har sin egen toppdomän eu.

Under de flesta toppdomäner är det rätt fritt att registrera domännamn, så toppdomän och domännamn anger snarare den bild webbplatsen vill ge än organisationens verkliga natur. Till exempel används ”to” och ”nu” allmänt som generella domäner (medan domännamn under edu.to är reserverade för verkliga utbildningsinstitutioner i Tonga). Webbplatser med domäner under restriktiva toppdomäner som stämmer överens med webbplatsens natur uppfattas i allmänhet som mer seriösa. ”fi” och ”sv” har gått rykte, men är inte lika kända internationellt som ”com” och ”org”.

Domännamnssystemet använder endast bokstäverna a-z, siffror och bindestreck (stora och små bokstäver är likvärda). Det går nuförtiden att registrera domännamn med andra tecken (åäö etc.), men dessa omkodas då med de tillåtna tecknen och ett sådant namn rekommenderas inte som primärt namn. Vilka ytterligare tecken som tillåts varierar enligt toppdomän (under ”se” tillåts de bokstäver som används i nordiska språk och i officiella minoritetsspråk, under ”fi” de som används i finska, svenska samt enare- nord- och skoltsamiska).

Om det ligger pengar i en webbplats är det sannolikt att andra registrerar liknande domännamn och erbjuder sig att sälja dem för rätt stora summor. Om man tror sig vara tvungen att betala är det bättre att genast själv registrera ett antal av dessa närliggande namn.

Då man registrerar ett domännamn måste man besluta i vems namn det registreras, vilket avgör vem som har rätt att besluta om användningen, samt uppge kontaktuppgifter för administrativa och tekniska ändamål. I många domäner förutsätts dessutom att namnservrar och annan teknisk infrastruktur fungerar. Webbhotell och en del andra företag och organisationer kan åta sig att sköta domänen för en mycket måttlig ersättning, men många webbhotell registrerar domännamnet åt sig själv om man inte kommit överens om annat, och då är det svårt att bryta kundförhållandet.

E-post och andra kontaktmetoder

En seriös domän och en seriös organisation skall gå att kontakta. På webbplatsens huvudsida bör finnas en tydlig länk till kontaktuppgifter och uppgifter om den bakomliggande organisationen. Det är bra att ange telefonnummer, post- och besöksadress och en eller flera e-postadresser. Ofta skapar man också ett HTML-formulär, genom vilket besökare kan berätta om felsituationer, kommentera webbplatsen eller kontakta organisationen. En del användare föredrar e-postadresser, andra föredrar formulären. Formulärens innehåll förmedlas vanligen till en e-postadress som inte framgår ur formulärets HTML-kod.

Förutom den information som anges explicit förväntas ofta vissa e-postadresser finnas oberoende av om de nämns. Den viktigaste är postmaster-adressen, som förutsätts fungera och har en särställning i e-postprogramvara. Adresserna webmaster och abuse antas också ofta finnas. Också om webbhotellet tar hand om e-posten till dessa adresser kan det vara nyttigt att låta e-posten skickas också till någon i er organisation (lätt att ordna med alias-funktionen), så att ni åtminstone genom stickprov kan få en uppfattning om eventuella klagomål.

Om webbhotellet sköter hela domänen för er, se till att e-posten dirigeras till någon som tar hand om den. I synnerhet gäller detta de ovannämnda adresserna. E-posten dirigeras ofta skilt från annan trafik, enligt MX-fältet på DNS-servern, och kan alltså hanteras av någon helt annan server under någon annan domän. Åtminstone adressen ”postmaster” skall fungera så väl för maskinens namn (www.domän.example.org) som för huvuddomänen.

Det finns ingen konsensus om huruvida e-postadresser skall vara synliga. Många organisationer uppger att e-postadresserna är av formen förnamn.efternamn@domän.example.com och hoppas att skräppostautomater skall ha svårt att härleda de egentliga adresserna. Ett problem här är att namn med vissa bokstäver (åäö) ofta särbehandlas, ett annat att det kan finnas fler personer med samma för- och efternamn. Instruktionerna borde fungera eller ge vettiga felmeddelanden för alla personer i organisationen.

Oberoende av de personliga adresserna bör organisationen ha adresser som kan anges explicit. Ovannämnda speciella adresser skall bevakas, men skräppostproblemet kan vara mindre för dem, så de ofta läses av folk med beredskap att effektivt anmäla missbruk. Om andra adresser drabbas av alltför stora mängder skräppost är det tänkbart att byta ut dem, med tillräcklig övergångstid.

Funktioner på servern

Innan man gör upp avtal för sin webbplats gäller det att fundera på vilka funktioner man behöver. Beroende på webbhotell eller server kommer en del funktioner på köpet, medan andra måste installeras skilt, och kan finnas tillgängliga endast för extra betalning eller inte alls.

Kontrollera också om det webbhotell ni tänker använda har gott rykte. Ni vill inte att servern ofta är otillgänglig eller beter sig illa. Administrationen skall svara på e-post, ge råd och åtgärda eventuella fel utan större dröjsmål. Organisationen skall följa god praxis ifråga om Internet-standarder. Och så vidare.

Webbsidorna

För statiska sidor, sidor som laddats upp på webbplatsen och därefter förmedlas till dem som frågar efter dem, behöver webbservern knappast någon kapacitet. Skivutrymme är billigt (också om kravet på driftssäkerhet gör det mycket dyrare än på en hemdator) och det som avgör kostnaderna är i första hand trafikvolymen.

De flesta webbservrar ger möjlighet till vissa ytterligare funktioner, såsom SSI (”server side includes”) som ändrar sidorna på enkla sätt, till exempel så att länkar till en nyhetssida läggs in på ett antal andra sidor, eller vissa formulärhanterare, som till exempel kan skicka ifyllda webbformulär till en överenskommen e-postadress.

Om man vill kunna generera sidor alltefter ställs betydligt större krav på servern. Till detta används ofta skriptspråket PHP. Man kan också ha enskilda skript till exempel för en gästbok, ofta skrivna i PHP, Perl eller Python. Ett webbhotell kan ställa färdiga skript till förfogande eller tillåta att man laddar upp egna skript. Det senare kräver ofta skild överenskommelse. Vilka språk och vilka funktioner som finns tillgängliga beror ofta på om servern kör under någon Unix-variant eller under Windows.

Numera är det vanligt att en hel webbplats innehåll lagras i en databas, ofta MySQL. Detta ger stor flexibilitet, men systemet är sällan överskådligt för en lekman. Kontrollera att systemet någorlunda enkelt stöder de funktioner du behöver och att du inte blir fången i ett system som kanske senare visar sig olämpligt.

Om webbplatsen skall skötas genom ett så kallat innehållshanteringssystem (CMS, content management system) krävs att behövlig infrastruktur finns tillgänglig. Antingen bör systemet finnas färdigt installerat eller också måste någon ha möjlighet att installera och underhålla systemet. Vanligen förutsätts en databas, där sidinnehåll, användaruppgifter etcetera lagras.

Uppladdning och inloggning

För att en webbserver skall vara användbar måste man kunna ladda upp sidorna. Detta görs med ett filöverföringsprogram som ftp, ftps, scp eller sftp. Det traditionella ftp skyddar varken lösenord eller själva sidorna mot attacker från någon som kommer åt nätet på vägen: lösenorden kan snappas upp och sidorna förvanskas, det senare är allvarligt om du erbjuder datorprogram och någon byter ut dem mot trojanska hästar. Därför bör antingen ftp över ssl (ftps) eller förbindelser genom ssh (scp, sftp) användas. En del webbhotell erbjuder endast ren ftp som standard.

För mer avancerade funktioner kan det vara bra att kunna logga in på serverdatorn. Det är frustrerande om många stora filer måste laddas upp på nytt endast för att man skall kunna ändra en e-postadress som är angiven på ett standardiserat sätt och alltså skulle vara lätt att ändra automatiskt. Sidor kan också genereras automatiskt dagligen eller enligt behov genom att kombinera en standardmall och föränderligt innehåll.

För vissa webbplaster är det väsentligt att kunna ladda ner filer från en annan webbplats och sedan själv publicera dem, som sådana eller i förändrat skick. Detta gäller i synnerhet om man ”speglar” andra webbplatser. ftp och scp erbjuder möjlighet att göra detta utan att filerna behöver kopieras till den egna datorn. Funktionaliteten kan vara avstängd på servern.

Det kan överhuvudtaget vara bra att kunna köra program på serverdatorn, till exempel kan veckans kampanj laddas upp i förväg men aktiveras först tidigt på måndag morgon. Vilka program och funktioner man har tillgång till varierar, dels enligt avtal, dels enligt vilket operativsystem som används.

Om mer än en mänska skall arbeta med webbplatsen är det bra om alla får ett eget användarnamn och lösenord, dels så att man vet vem som gjort vad, dels så att var och en kan ändra sitt lösenord utan att tänka på andra.

Instruktioner för webbservern

Ofta kan man ge instruktioner om hur enskilda kataloger eller filer skall behandlas genom att lägga in speciella filer i de berörda katalogerna (.htaccess med apache). På så sätt kan man se till att teckenkodning och filtyp anges rätt, korrigera felaktiga förvalda värden på servern eller omdirigera förfrågningar då visst (i samband med serverbyte allt!) innehåll flyttats annanstans.

Vilka funktioner man har möjlighet att styra beror på servern och dess inställningar och alltså delvis på det avtal man gjort.

Webbplatsens struktur

• Logisk, både internt och som den syns utåt.
• Enligt tema, administration, språk eller målgrupp?
• Planera också med tanke på underhåll: håll vissa delar fria från föränderligt data och koncentrera sådant som måste uppdateras genast till enstaka sidor

Länkröta: Se till att gamla adresser fortsätter att fungera. Planera strukturen så att detta inte blir svårt. Undvik att ha värdefullt innehåll direkt på en sida vars innehåll byts ofta. Framsidans substans (dagens nyhet etc.) bör finnas också på en adress som håller sig (den adressen passar som "läs vidare" på framsidan, så att intresserade besökare direkt bokmärker den bestående adressen).]

För att besökare skall hitta på webbplatsen, för att de inte skall bli frustrerade och för att de skall kunna länka till innehållet på ett ändamålsenligt sätt är det viktigt att webbplatsens struktur är logisk och tydlig. Om samma sida eller samma innehåll nås olika vägar skall detta framgå. Gör skillnad mellan länkar till mer specifika sidor i samma helhet och korsreferenser. [...] Besökaren skall kunna avgöra att viss information inte finns istället för att behöva irra omkring sökande efter den.

Vanare webbanvändare kan härleda webbplatsens struktur ur URL-adresserna, förutsatt att dessa är meningsfullt konstruerade. Också då webbsidorna hämtas ur en databas kan man utforma adressen som om det gällde ett filträd, med ”kataloger” som motsvarar olika logiska helheter.

Underhållet av webbplatsen är lättare om strukturen är klar också ut organisationens synvinkel, till exempel så att en enskild person ansvarar för en viss helhet, och inte någon sida här och någon där, eller så att helheterna motsvarar den terminologi som används inom organisationen. En sådan struktur behöver inte sammanfalla med vad som är intuitivt för besökaren och visst arbete måste läggas på att sammanjämka kraven, förklara strukturen för antingen besökaren eller dokumentera strukturen med tanke på dem som skall under underhålla webbplaten.

Det är möjligt att ha parallella strukturer, så att en sida finns på ett ställe i den struktur besökaren ser och på ett annat i den struktur den som underhåller webbplatsen ser. En sådan lösning måste planeras och dokumenteras noga för att båda strukturerna skall fungera. Annars händer det lätt att texterna på webbsidorna utgår från den för besökaren osynliga strukturen.

Om webbplatsen helt eller delvis är översatt till olika språk eller om delar av webbplatsen är skriven för olika språk, måste detta beaktas vid planeringen av webbplatsens struktur. Se språkproblematiken nedan.

Med tanke på underhållet är det bra om man kan hålla delar av webbplatsen fri från föränderlig information och koncentrera information som måste hållas fullt uppdaterad till några få sidor. Till exempel kan kontaktuppgifter finnas i en fil, som dagligen automatiskt infogas i de webbsidor där de behövs. Undvik att tala om nutida förhållanden i en historik, som i sig själv inte behöver kontrolleras särskilt ofta.

Statiskt eller dynamiskt

• Vem gör sidorna, den som känner ämnet eller någon som kan tekniken?
• Olika lösningar för att förenkla arbetet, till exempel mallar, inkludering av standardkod (och CMS)
• Sidgenerering vid uppdatering, dagligen eller enligt efterfrågan
• Mellanlagring av genererade sidor
• Cache-kontroll
• Innehållshanteringssystem (CMS)

Parallellt innehåll

Ibland vill man ha samma eller liknande innehåll presenterat på olika sätt, till exempel för olika målgrupper. [...]

Olika språk

• */sida.html.sv versus svenska/*/sida.html versus */sida.html?lang=sv versus */sida.html med kex
• Språket är bra att ange explicit, så att länkar kan ges vidare med eller utan språkspecifikation och problem lösas också av användaren
• ...
• Se närmare nedan under Speciella problem: Flerspråkiga webbplatser.

Självständiga helheter

Ofta kan det finnas behov av att hålla någon helhet utanför den övriga administrationen, till exempel då ett innehållshanteringssystem inte kan hantera webbsidor som hämtas som sådana från något annat ställe eller då det uppstår behov att ge större befogenheter åt en grupp att utforma vissa sidor.

[...]

Webbsidorna

[Om hur själva webbsidorna skall utformas: innehållets disposition, metainformation, layout, delar som kan inkluderas från andra filer, javascript, CSS och andra tekniker, ...]

[Här beskrivs främst sidan så som den ser ut ur webbläsarens och ur läsarens synvinkel. Hur den konstrueras beskrivs delvis under #Webbplatsens struktur.]

• Du har ingen kontroll över webbläsaren. Låt det vara en styrka att den känner användarens behov
• Klar sidstruktur. Börja med det väsentliga (CSS gör det möjligt att placera om element).
• Rubrik, titel och nyckelord; gör sökningar lätta
• Olika tekniker och möjligheter
• Egenskaper som stöds eller inte stöds av webbläsare
• Användbarhet och hinderlöshet

Material som skapas separat

Protokoll, nyhetsbrev etc.

• konfidentiell eller icke-offentlig information?
• format, något gemensamt?
• upphovsrätt

Ofta har man tillgång till intressant material som mer eller mindre automatiskt kunde publiceras på webbplatsen. Detta kan vara organisationens tidning eller nyhetsbrev, årsberättelser, mötesprotokoll eller artiklar som någon i organisationen publicerat annanstans. Tyvärr måste dessa ofta anpassas på något sätt innan de kan publiceras på webbplatsen.

Vad gäller föredragningslistor, protokoll eller beslutslistor förekommer det ibland att konfidentiella ärenden behandlas och rätt ofta kan ärenden eller vissa detaljer om dessa vara olämpliga att publicera, också om man för det mesta är öppen. Den som publicerar informationen på webbplatsen är sällan den som skall bedöma vad som skall publiceras. Det är alltså viktigt att slå fast vilken typ av uppgifter som publiceras automatiskt och hur man anger att någonting inte skall publiceras. Den som producerar materialet (mötessekreteraren) måste vara medveten om publiceringspraxis.

Det är också viktigt att i mån av möjlighet använda sådana filformat att materialet kan publiceras utan omfattande omarbetning. Material från ordbehandlare kan automatiskt omvandlas till HTML och PDF, men med relativt enkla åtgärder blir resultatet betydligt bättre (strukturinformation, metainformation, bilagor, referenser och länkar). Märk också att ordbehandlare kan lägga in osynlig eventuellt känslig metainformation i filerna.

Kontrollera att författare och fotografer ger tillstånd till webbpublicering. [...]

=== Gästböcker och bloggar

Flerspråkiga webbplatser

De flesta webbplatser som utvecklas till något litet större kommer att behöva understöda mer än ett språk. I Finland har vi åtminstone det andra inhemska. Också i Sverige vill man ofta ha åtminstone någon information på engelska. För många webbplatser är också andra språk aktuella.

Att hålla informationen uppdaterad på alla språk är svårt. Likaså att hålla webbplatsens struktur logisk för den som i första hand använder något annat än huvudspråket. Det gäller att administrera uppdateringarna väl.

Därtill kommer tekniska problem. Teckenkodningen måste antingen stöda alla språken eller också måste olika teckenkodning användas och anges på olika sidor. Då viss information hanteras oberoende av språk måste man se till att anslutande texter anpassas.

Val av språk

HTTP innehåller en mekanism (”content negotiation”) för att automatisk kunna erbjuda sidor på rätt språk. Tyvärr anger många webbläsare automatiskt sitt språk som användarens språk, vilket gör att uppgiften inte är pålitlig. Många webbplatser väljer att strunta i uppgiften.

I Sverige och Finland kan man ofta utgå från att om webbläsaren uppger antingen ett annat språk än engelska eller alternativa språk så är valet åtminstone i någon mån medvetet. I dessa fall är alltså webbläsarens språk en mycket god första gissning vad gäller önskat språk, och att respektera webbläsarinställningarna är att visa respekt för användaren, i de fall han är medveten om dem. Ofta är ändå inställningarna gjord av någon annan (i synnerhet då webbläsaren uppger ”en” eller ”en-us” som enda språk).

Också då besökaren medvetet valt språk kan han vilja använda också ett annat språk, till exempel för att jämföra innehållet på olika språk eller av speciella tillfälliga orsaker. Därför måste man tillfälligt kunna välja ett annat språk oberoende av hur det primära språket härletts. Språkbytet skall helst leda till motsvarande sida på det andra språket, mycket ogärna till att användaren förpassas till huvudsidan. Med tanke på jämförelser är det också problematiskt om användaren inte längre kommer åt sidorna på det tidigare språket. Val av primärspråk och val av språk för en enskild sida bör alltså gärna hållas åtskilda.

[mer konkreta råd, också hur olika färdiga system beter sig]

Översättning

• vilken version skall översättas: text, html, php, annan?
• teckenkodning: normalt utf-8, men annars krävs sätt att ange kodning för webbservern, oberoende måste webbservern ha rätt information
• oöversatta sidor
• sidor med föråldrad översättning
• sidor översatta endast i förkortad version

För hur sidorna kan namnges eller ordnas hierarkiskt, se även ovan Webbplatsens struktur: Parallellt innehåll

Underhåll

[Underhållet skall planeras i förväg eller också glöms det bort. Systematik!]

[Webbplatsen kan också byggas så att den är lättare att underhålla, till exempel genom att hålla vissa delar fria från föränderligt data och koncentrera sådant som måste uppdateras genast till enstaka sidor]

Ansvar och rättigheter

• Ge olika personer ansvar för olika delar av webbplatsen, så att varje del har en ansvarsperson
• Se till att ansvaret överflyttas då personen lämnar organisationen (vilket förutsätter att man vet vad ansvaret gällt).
• Lämpliga rättigheter, bland annat så att man inte kan förorsaka överraskande stor skada med misstag.
• ...

Säkerhetskopiering

• Bör skötas systematiskt.
• Räcker webbhotellets åtgärder? Håll åtminstone någon kopia själv, med tanke på katastrofer i kundförhållandet eller i skötseln av servern.
• Utkast och verktyg kan finnas på lokala arbetsstationer. Hur hanteras de?
• Olika hotbilder: misstag, dataintrång, bitröta, blixt, eldsvåda.
• Skadan kan undgå upptäckt, så även äldre kopior viktiga.
• Hur hanteras hemliga uppgifter? Krypterade säkerhetskopior kan visa sig vara värdelösa.
• ???

Uppdatering

• Planera i förväg
• Bestäm behovet av uppdatering per logisk helhet eller katalogstruktur. Notera undantag. Se till att information som behöver snabbare uppdatering inte smyger sig in.Se till att sidors natur är tydlig.
• Bestäm ansvar för uppdatering av olika sidor eller för olika situationer, också för katastrofer (då webbsidorna plötsligt kan besökas av många i behov av info)
• Bestäm tidpunkter för uppdateringarna: de flesta sidor bör t.ex. kontrolleras inför terminsstart, historiken kanske inför nästa jämna fem år, notera också specialsituationer (vad händer om telefonnumret ändras, glöms det gamla numret kvar någonstans?)
• Datum för sista uppdatering: rättades en detaljuppgift eller kontrollerades allt innehåll?
• Undvik länkröta: gamla artiklar bör finnas kvar och bör nås via den gamla adressen. Sidor där nytt innehåll ersätter gammalt skall hanteras så att besökare kan länka antingen till den nyaste versionen eller till en specifik version.

Omdirigeringar

Om man har kontroll över namnservern för sin domän kan man fritt (med viss övergångstid) flytta domänen från en dator till en annan, då man till exempel behöver större kapacitet eller inte är nöjd med servicen. Namnservern måste vara fullkomligt pålitlig, så ofta delegeras driften till lämplig firma.

Också på själva servern kan man ordna omdirigeringar. Dessa är särskilt viktiga efter en omstrukturering av innehållet på webbplatsen, då visst innehåll flyttats annanstans och efter att man bytt domännamn eller serverdator. Vissa webbhotell använder omdirigeringar för att kompensera problem med webbhotellets struktur.

Omdirigeringar på själva webbsidan kan göras genom meta-taggar i HTML-koden eller genom javascript. Dessa fungerar inte med alla webbläsare.

Ändringar med hjälp av namnservern

[borde detta behandlas i skilt avsnitt om DNS?]

Omdirigeringar genom webbservern

HTTP, protokollet som används för att ladda ner webbsidor, ger möjlighet till ett antal olika omdirigeringar. Servern kan bland annat tala om att sidan flyttat, tillfälligt hittas på viss adress, att svaret på förfrågan (feedback för blankett) hittas på viss adress, att flera dokument motsvarar förfrågan (t.ex. olika språk eller filformat).

Eftersom webbservern sällan kontrollerar sidinnehåll innan de ger svar på en förfrågan måste omdirigeringarna styras genom serverns konfigurationsfiler.

[Samspel med sökmaskiner, se till att en populär sida inte försvinner genom flyttet (HTTP: Gone?).]

Omdirigeringar i webbsidan

Eftersom den ansvariga för en viss webbsida inte alltid har möjlighet att ändra i webbserverns inställningar lägger man ofta in omdirigeringar som speciella taggar i HTML-dokument eller med javascript. Dessa stöds inte av alla webbläsare.

Lögn, förbannad lögn, statistik

[Om att följa upp användningen]

Webbservrar för i allmänhet rätt noggrant bok över användningen. Loggfilerna kan ge en fingervisning om vilka sidor som används flitigt och vilka som inte hittas, vilka icke-existerande adresser som efterfrågas och vilka vägar besökare hittar till olika sidor. Också de flesta attackförsök lämnar spår. Det finns en mängd programvara som hjälper att analysera loggarna.

Vid sidan av loggarna på den egna servern finns ett antal system för att följa med användningen via en tredjepartsserver. Dessa bygger i allmänhet på att en del av innehållet (reklamer eller minimala, i praktiken osynliga, bilder) hämtas från den andra servern, varvid denna tredje part får tillgång till motsvarande information.

Ofta drar man alldeles för långtgående slutsatser av loggarna och i synnerhet av statistik via tredje part. Många webbläsare filtrerar bort javascript och länkar till bilder som tredjepartsprogrammen bygger på. Likaså kan de av olika orsaker uppge felaktig information. Mellanservrar, sökrobotar och andra program förvrider också statistiken.

Försök att minska felkällorna leder ofta till större problem, till exempel till att webbläsare som inte använder javascript inte noteras, till långa svarstider (då webbservern måste kontaktas istället för att sidan laddas från mellanservern över ett snabbt intranät), till större belastning på servern och till att vissa användargrupper har svårt att använda webbplatsen (då servern endast betjänar ”sammarbetsvilliga” webbläsare).

Det finns inga pålitliga sätt att uppskatta felen i statistiken, men det är uppenbart att en betydande del av användarna inte statistikförs eller statistikförs fel. En del webbexperter anser att statistiken inte kan användas vettigt annat än för att uppskatta belastningen på webbservern.

Det finstilta

• Vem har kontrollen
• Omdirigering efter serverbyte
• ...

Bilagor

Webbprotokollen

• HTTP (”hypertext transfer protocol”) är det protokoll som webbläsaren och webbservern vanligen använder för sin kommunikation. Ibland används HTTPS, där kommunikationen är krypterad och där webbservern kan använda certifikat för att bevisa att webbplatsen är den rätta. Också till exempel FTP kan användas för filöverföring, och WWW-adresser (URL) kan ange också andra protokoll.
• HTML (”hypertext markup language”) är det märkspråk som i allmänhet används på själva webbsidorna. HTML-koden kan helt eller delvis genereras först när sidan efterfrågas, men ofta är sidan helt eller till största delen skriven som HTML. Webbservern förmedlar också andra typer av filer: rena textfiler, bildfiler, pdf-filer och filer i olika format som webbläsaren inte själv kan hantera.
• CSS (”cascading style sheets”) innehåller instruktioner om hur webbläsaren skall presentera olika element. I idealfallet beskriver HTML-koden endast webbsidans struktur och innehåll, medan utseendet sköts av webbläsaren, med hänsyn till CSS-instruktionerna. Användaren kan välja att avaktivera stödet för CSS eller använda egna CSS-definitioner istället för webbplatsens.
• Javascript eller Ecmascript är ett programmeringsspråk som används för att lägga in programkod i webbsidan, att köras av webbläsaren. Främst används språket för olika effekter och för att underlätta ifyllande av formulär. Tolken kan vara avaktiverad.
• Java är också ett programmeringsspråk för program som webbläsaren skall köra. Det används främst för små självständiga applikationer.
• Flash används istället för eller som ett komplement till HTML, främst för webbsidor som kräver avancerade effekter. Många av webbläsarens normala funktioner åsidosätts. Språket stöds inte i alla webbläsare.
• ActiveX är ytterligare ett programmeringsspråk. Med detta språk kan man i princip göra vad som helst med webbläsarens rättigheter, men koden skall i allmänhet undertecknas, så användaren kan avgöra om han vill lita på programmet. Språket tolkas endast av Microsofts webbläsare.
• SSI (”server side includes”), PHP, Perl och Python ger möjlighet att modifiera eller skapa webbsidorna då de efterfrågas, innan de skickas till webbläsaren. I princip kan vilket som helst programspråk användas, men dessa är enkla att använda för kortare programsnuttar och har gott stöd för denna typs användning.
• CGI (”common gateway interface”) beskriver samverkan mellan webbservern och program som skall köras som svar på en förfrågan. Programmen är ofta skrivna i PHP, Perl eller Python.

Programvara

• Webbservrar
• Programspråk
• Skriptsamlingar