HTTP

HTTP er forkortelsen for Hypertext Transfer Protocol. Det er den protokol, som en browser, en server og mange andre webklienter bruger, når de udveksler forespørgsler og svar. Når du åbner en side, beder browseren om en ressource, og serveren svarer med indhold, status og tekniske oplysninger.

En webside består normalt af mange ressourcer. Først hentes HTML-dokumentet. Derefter kan browseren hente stylesheets, skrifter, billeder, scripts og data fra et API. Hver af disse udvekslinger følger HTTP-regler, selv om brugeren oplever dem som én samlet side.

HTTP beskriver blandt andet metoder som GET og POST, statuskoder som 200 og 404 samt headers, der fortæller noget om format, cache, sprog og sikkerhed. Protokollen bestemmer ikke, om indholdet er godt eller sandt. Den beskriver, hvordan beskederne udveksles og forstås.

Forskellen mellem HTTP og HTTPS er, at HTTPS beskytter forbindelsen med TLS. Det gør det langt sværere for andre på forbindelsen at læse eller ændre trafikken undervejs. På en moderne offentlig hjemmeside bør den synlige adresse derfor begynde med https://.

HTTP-opslaget handler om selve protokollen. Det eksisterende opslag om HTTPS går tættere på den krypterede forbindelse, certifikater og browserens sikkerhedsmarkering. Vores artikel Hvad er HTTP og HTTPS? sammenligner de to i en bredere hjemmesidesammenhæng.

Som almindelig hjemmesideejer behøver du ikke skrive HTTP-beskeder manuelt. Men en grundlæggende forståelse gør fejlsøgning lettere. Browserens udviklerværktøjer viser de enkelte forespørgsler under fanen Network. Her kan man se URL, metode, statuskode, svartid, størrelse og headers.

Nogle almindelige metoder er:

• GET: Bruges typisk til at hente en side, et billede eller data.
• POST: Bruges ofte, når data sendes, for eksempel fra en formular eller ved oprettelse af en ordre.
• HEAD: Henter headers uden selve indholdet og kan bruges til kontrol af en ressource.
• PUT, PATCH og DELETE: Ses ofte i API’er, hvor data oprettes, ændres eller slettes.

Statuskoderne viser resultatet. En 200-kode betyder normalt, at forespørgslen lykkedes. En 301-redirect fortæller, at ressourcen er flyttet permanent. En 404-fejl betyder, at serveren ikke fandt den ønskede ressource. En 500-kode peger på en fejl på serveren.

Headers styrer eller beskriver meget af det, der sker rundt om indholdet. Content-Type fortæller, om svaret er HTML, JSON eller et billede. Cache-Control hjælper browseren og et eventuelt CDN med at afgøre, hvor længe en kopi kan bruges. Andre headers håndterer komprimering, sprog, cookies og sikkerhedspolitikker.

En offentlig hjemmeside bør have et gyldigt SSL-certifikat og sende alle HTTP-adresser videre til den tilsvarende HTTPS-adresse. Det gælder også variationer med og uden www, hvis begge kan ramme serveren. Målet er én tydelig version af hver side.

Kontrollér også blandet indhold. Det opstår, når selve siden bruger HTTPS, men et billede, script eller stylesheet stadig hentes over HTTP. Browseren kan blokere ressourcen eller fjerne sikkerhedsmarkeringen. Gamle hardcodede links og indlejrede tredjepartsfiler er typiske årsager.

På en WordPress-hjemmeside håndteres det meste gennem server, CMS og plugins. Men en teknisk gennemgang hos et webbureau bør stadig kontrollere statuskoder, redirects og headers i stedet for kun at se, om forsiden åbner.

En virksomhed har flyttet sin hjemmeside til et nyt webhotel. Adressen med HTTPS virker, men den gamle HTTP-version viser stadig en separat kopi af forsiden. Nogle eksterne links peger på HTTP, mens sitemap og interne links bruger HTTPS.

I browseren ser de to sider ens ud, men teknisk findes der to versioner. Det kan splitte statistik, skabe unødige redirects og gøre det uklart, hvilken URL søgemaskiner skal behandle som hovedversion.

Løsningen er at konfigurere serveren, så alle forespørgsler til HTTP straks får en permanent redirect til den præcise HTTPS-adresse. En forespørgsel til http://eksempel.dk/kontakt/ skal altså ende direkte på https://eksempel.dk/kontakt/ og ikke gennem flere mellemtrin.

Under kontrollen viser Network-fanen også, at et gammelt JavaScript stadig hentes fra en HTTP-adresse. Browseren blokerer filen på HTTPS-siden, og kontaktformularen virker derfor ikke. Scriptets adresse opdateres, og siden genindlæses uden blandet indhold.

Efter ændringen kontrolleres flere sidetyper, ikke kun forsiden. Der testes produktbilleder, formularer, downloads og gamle kampagnelinks. Derefter ryddes cache, så tidligere kopier ikke skjuler resultatet.

Eksemplet viser, hvorfor HTTP ikke kun er et ord foran domænet. Metoder, statuskoder, redirects og ressourcer påvirker det, brugeren faktisk oplever.

Den mest almindelige misforståelse er, at en hængelås betyder, at hjemmesiden er sikker i enhver forstand. HTTPS beskytter forbindelsen. Det garanterer ikke, at virksomheden er ærlig, at WordPress er opdateret, eller at formularen behandler data korrekt.

En anden fejl er at installere et certifikat uden at lave redirects. Så virker HTTPS, men HTTP-versionerne lever videre. Der bør være en bevidst og testet viderestilling, ikke bare to adresser, som begge viser indhold.

Redirect chains er også unødige. Hvis HTTP først sender til HTTPS uden www og derefter videre til HTTPS med www, kræver det flere forespørgsler. Konfigurationen bør så vidt muligt sende direkte til slutadressen.

Pas på med at ændre alle adresser gennem en hurtig søg og erstat uden backup. Interne data, serialiserede WordPress-felter og eksterne systemer kan kræve særskilt håndtering. Brug en metode, der passer til det konkrete CMS og databaseformat.

Endelig bliver HTTP-fejl ofte behandlet som et enkelt SEO-problem. De kan også ramme betaling, login, billeder, formularer og tredjepartsintegrationer. Fejlsøg derfor ud fra den konkrete forespørgsel og ikke kun ud fra den synlige side.

HTTP har udviklet sig gennem flere versioner. HTTP/1.1, HTTP/2 og HTTP/3 bruger de samme grundlæggende begreber om forespørgsler, svar, metoder og statuskoder, men transporterer data forskelligt. HTTP/3 bruger QUIC og er designet til moderne, sikre forbindelser.

Versionen håndteres normalt af browser, server og hostingudbyder. En hjemmesideejer skal sjældent vælge den i WordPress. Det relevante er at bruge en opdateret serveropsætning og kontrollere, at funktioner og cache virker efter ændringer.

HTTP er i udgangspunktet stateless: hver forespørgsel kan behandles uden automatisk hukommelse om den forrige. Cookies, tokens og serverdata bruges derfor til login, kurve og andre forløb, der skal huske en bruger over flere forespørgsler.

Det er også gennem HTTP, at søgemaskinens crawler modtager statuskoder, redirects og indhold. En teknisk korrekt respons gør ikke siden værdifuld alene, men en forkert respons kan forhindre godt indhold i at blive hentet eller indekseret.

Google har i mange år anbefalet HTTPS og bruger sikre forbindelser som et signal. I praksis er browserens advarsler og brugerens tillid dog grund nok til at vælge HTTPS, også uden at diskutere størrelsen på en rankingeffekt.

HTTP arbejder sammen med andre dele af internettet, men er ikke det samme som dem. DNS hjælper med at finde den server, et domæne peger på. TLS beskytter forbindelsen. HTTP beskriver derefter selve udvekslingen af forespørgsel og svar. Når man skiller lagene ad, bliver det lettere at finde ud af, om en fejl ligger i domænet, certifikatet, serveren eller applikationen.

En URL indeholder også flere dele, der får forskellig betydning i en HTTP-forespørgsel: protokol, domæne, sti og eventuelle parametre. Serveren kan returnere forskelligt indhold afhængigt af metode, sti, headers og brugerens adgang. Det er derfor ikke altid nok at teste forsiden, når en bestemt fil eller funktion fejler.

Ved fejlsøgning bør man gemme den konkrete statuskode og den URL, der udløser problemet. Formuleringen “hjemmesiden virker ikke” er svær at handle på. “POST-forespørgslen til formularens endpoint returnerer 403” peger derimod på et bestemt trin, som kan undersøges.

HTTP er dermed et grundlag for næsten alt på nettet. Man behøver ikke kunne standarden udenad, men metoder, statuskoder, headers og sikker forbindelse er nyttige at kende, når en hjemmeside ikke opfører sig som forventet.