- Jeg klikker av HTTP-headere!

- Over en million treff på Google, med tråder fra desperate utviklere, forteller Jørgen, som er en av dem.

Jørgen blir forvirra av HTTP-headere. Som ikke er det samme som head-taggen i denne HTML-koden. 📸: Ole Petter Baugerød Stokke
Jørgen blir forvirra av HTTP-headere. Som ikke er det samme som head-taggen i denne HTML-koden. 📸: Ole Petter Baugerød Stokke Vis mer

Av og til blir jeg megasinna på Google. Det finnes nemlig ikke noe som gjør en utvikler mer eitranes førrbanna enn å ikke finne et konsist svar på en problemstilling man sitter fast på i Google-søket.

Du vet; den følelsen når man har klikket seg gjennom et titalls StackOverflow-tråder som er innom tematikken, men lissom ikke helt svarer på det man lurer på.

Når man gir opp StackOverflow, beveger seg over i rare Medium-bloggartikler og tar koderåd fra MightyKnightNoobLazor, som bruker en PowerPuff-GIF som avata - da begynner man stille visse spørsmålstegn ved ens egne karrierevalg.

Som regel så går jeg ned denne stien når jeg prøver å finne ut av en HTTP-header-feil, slik som CORS, Cookies, Cache eller noe annet møl. Og jeg blir aldri klokere.

La meg forklare.

Frustrerende teknologi

Om du ikke er så bevandret i HTTP-headere forstår jeg deg. Som oftest trenger man ikke å forholde seg til dem i det hele tatt.

Som oftest er de jo usynlige.

Kort forklart - når du gjør en HTTP-request, enten det er å laste en nettside i nettleseren din eller gjøre en GET-request til et API, blir to ting utvekslet:

  1. HTTP-kroppen, som inneholder den faktiske dataen du utveksler, slik som HTML-en fra serveren, eller JSON-dataen du sender i en POST-beskjed.
  2. HTTP-hodet, som forøvrig ikke må forveksles med <head>-taggen i HTML (den er i HTTP-kroppen).

Jobben til HTTP-hodet er å gi informasjon om HTTP-kroppen fra serveren til nettleseren, og fra nettleseren til serveren.

Det finnes et lastebil-lass med forskjellige datainnstillinger man kan sende over i HTTP-hodet, med tvetydige navn og varierende logikk. Og de har mye makt:

  • Den cookien som plutselig ble satt i nettleseren din? Den kom mest sansynlig som en Set-Cookie-attributt i headeren.
  • Grunnen til at du ikke får oppdatert CSS-en på sida di, selv om du har oppdatert CSS-fila? Mest sansynlig fordi attributtet Cache-Control sier til nettleseren din at den skal blåse i oppdateringer.
  • Får du en merkelig XMLHttp-request failed-greie i konsollen når du prøver å hente data i React? Sikkert fordi Access-Control-Allow-Origin attributtet er satt feil.
«Det finnes et lastebil-lass med forskjellige datainnstillinger man kan sende over i HTTP-hodet, med tvetydige navn og varierende logikk.»

Hva faen er Lax?

Som om ikke attributtene i seg selv er frustrerende nok, har hvert attributt en snodig syntax som de forventer.

Ta Set-Cookie, for eksempel; attributtet man bruker når man vil fortelle nettleseren om å sette en cookie man har opprettet på server-siden.

Set-Cookie har i utgangspunkt formatet:

Set-Cookie: <cookie-name>=<cookie-value>

Men så finnes det også en haug med attributter man kan slenge på her, som Expires, Max-Age, Domain, Path, Secure, HttpOnly og SameSite:

// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

SameSite har forøvrig tre innstillinger: Strict, Lax, og none. Hva faen er Lax?!

Ta gjerne en svipptur innom Set-Cookie-siden til MDN og kjenn hvordan hjernebarken umiddelbart begynner å pulsere i frykt.

Andrea, Caroline, Jim og Sharo Corr i The Corrs skulle bare visst hvor forhatt deres navnefetter CORS er blant utviklere. 📸: CC BY 3.0 / Wikipedia
Andrea, Caroline, Jim og Sharo Corr i The Corrs skulle bare visst hvor forhatt deres navnefetter CORS er blant utviklere. 📸: CC BY 3.0 / Wikipedia Vis mer

CORS, du mener bandet?

Mjehe, neida, jeg snakker ikke om det snedige felespillende familiebandet The Corrs fra Irland, men Cross Origin Resource Sharing.

En mekanisme som bruker HTTP-headere til å fortelle en webapplikasjon om den har tilgang til en annen tjeneste på nettet. For eksempel om man vil kalle et API på et domene, fra en nettside på et annet domene.

En CORS-feil resulterer som oftest i den noe kryptiske feilmeldingen:

"Access to XMLHttpRequest at '...' from origin '...' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status."

Det finnes over en million treff på Google om temaet, som stort sett inneholder tråder fra desperate utviklere som prøver å få hjelp. For hva er preflight request? Hva er XMLHttpRequest? Og hva er access control check?

Temaet er så komplisert at MDN har viet et milelangt dokument til å forklare CORS, alt på grunn av et attributt i HTTP-hodet: Access-Control-Allow-Origin.

«Helt ærlig angrer jeg på at jeg ikke bruker mer tid på å sette meg inn i det.»

Skulle ønske jeg var flinkere

Ja, jeg hører deg mister Devops-geni: Dette er noe jeg bør kunne som utvikler.

Og ja, du har joggu meg helt rett. Helt ærlig angrer jeg på at jeg ikke bruker mer tid på å sette meg inn i det hver bidige gang jeg får en HTTP-header-feilmelding.

Jeg skulle ønske jeg var fyren som tok i mot, trøstet, og forklarte hoverende hva man skal gjøre, når fortvilte kollegaer banker hodet i pulten over uforståelige HTTP-header-problemer.

Jeg skulle gjerne vært han fyren som nonchalant inspiserte network-tabben i Chrome, og umiddelbart kunne tyde hvor feilen ligger.

Istedenfor er jeg fyren som kjører Chrome uten CORS, og hopper bukk over hele problemet.