HTTP headers opslag

HTTP headers opslag er et gratis værktøj, der henter alle de HTTP-responsheadere, som en URL returnerer ved en typisk GET-anmodning.

Hvad er HTTP-responsheadere?

HTTP-responsheadere er metadata, som en webserver sender før responsens indhold, for eksempel en HTML-side, et billede eller et JSON-dokument. De fortæller klienten, hvordan responsen skal fortolkes, cachelagres, omdirigeres eller beskyttes.

En HTTP/1.x-respons begynder normalt med en HTTP-statuslinje efterfulgt af headerne. I HTTP/2 og HTTP/3 overføres den tilsvarende status i pseudoheaderen :status. Statuslinjen i HTTP/1.x er teknisk set ikke en del af headerne, men vises ofte sammen med dem, fordi den fortæller, om anmodningen lykkedes. Status 200 betyder eksempelvis, at ressourcen blev returneret, 301 eller 302 angiver en omdirigering, 404 betyder, at ressourcen ikke blev fundet, og 500 angiver en serverfejl.

Headerne kan komme fra den oprindelige server, en reverse proxy eller et indholdsleveringsnetværk som Cloudflare. Nogle headere tilføjes eller fjernes, mens responsen passerer gennem disse systemer. Resultatet kan derfor beskrive mere end blot den applikation, der genererede siden.

Hvordan slår jeg HTTP-headere op?

Indtast hele den URL, du vil kontrollere, inklusive protokollen, for eksempel https://www.example.com/account. Værktøjet sender en typisk GET-anmodning fra sin server og viser de HTTP-headere, der modtages fra URL'en.

Brug præcis de URL-varianter, du vil undersøge, hvis du vil sammenligne responsheadere korrekt. Headerne for http://example.com, https://example.com og https://www.example.com kan være forskellige, fordi hver adresse kan have sine egne omdirigeringer, cacheregler og serverindstillinger.

URL'ens syntaks påvirker også anmodningen:

• Mellemrum er ikke gyldige som ubehandlede tegn i en URL og skal normalt procentkodes, typisk som %20 i en sti.
• ? indleder forespørgselsdelen, mens & og = ofte bruges i formularbaseret kodning af forespørgsler. De har dog ikke nødvendigvis disse funktioner i alle forespørgselsstrenge.
• Domænenavne med accenttegn eller ikke-latinske tegn behandles med IDNA og repræsenteres som ASCII A-labels, der typisk begynder med xn--. Tegn i stien kodes som regel først til UTF-8-byte og derefter med procentkodning.
• Et fragment, der begynder med #, behandles af browseren og sendes ikke med HTTP-anmodningen.
• Der findes ingen universel maksimal længde for URL'er. Meget lange URL'er kan blive afvist af en server, proxy eller applikation.

Hvordan læser jeg resultatet?

Undersøg de headere, der har betydning for den fejl, du prøver at finde. Der skelnes ikke mellem store og små bogstaver i headernavne, men værdiernes syntaks kan være versalfølsom.

Andre headere kan være specifikke for applikationen. Eksempelvis styrer Access-Control-Allow-Origin, hvilke origins der må læse en respons via anmodninger på tværs af origins i browseren. En Server-header kan angive software eller en proxy, men den er ikke et pålideligt bevis på den underliggende platform, da administratorer kan ændre eller fjerne den.

Praktiske eksempler på fejlfinding

Problemer med omdirigering er en almindelig grund til at undersøge headere. Antag, at https://example.com/old-page returnerer status 301 med Location: https://example.com/new-page. Det betyder, at serveren beder klienten om at hente den nye adresse. Ved at kontrollere hver destination efter tur kan du finde en omdirigeringsløkke eller et uventet skift mellem HTTP og HTTPS.

Hvis en side bag Cloudflare eller et andet CDN viser forældet indhold, skal du undersøge Cache-Control, Age, ETag og eventuelle udbyderspecifikke cacheheadere. En høj Age-værdi angiver den beregnede alder på den cachelagrede respons og kan omfatte tid i foranstående cacher. Den fortæller ikke, hvor længe et bestemt mellemled har opbevaret responsen. Værdien beviser heller ikke, at alle regionale cacher indeholder den samme version.

Hvis en API virker i et script på serversiden, men ikke i en browser, skal du undersøge Content-Type og CORS-responsheaderne, herunder Access-Control-Allow-Origin. Et JSON-endpoint, der returnerer text/html, leverer måske i virkeligheden en fejlside eller en loginside. Manglende tilladelse til adgang på tværs af origins kan få en browser til at blokere adgangen, selvom serveren returnerede status 200.

Headere kan også hjælpe med at undersøge et websted, der ser ud til at være utilgængeligt. En 503-respons peger på en midlertidig fejl på serveren eller i et foranstående system, mens 404 betyder, at den ønskede sti ikke blev fundet. Headere kan dog ikke bruges til at diagnosticere alle fejl. Hvis DNS-opslag, TCP-forbindelsen eller TLS-forhandlingen mislykkes, før der findes en HTTP-respons, er der muligvis ingen responsheadere at undersøge. Ping kan bruges til en separat kontrol af forbindelsen, mens HTTP/2 Kontrolværktøj kan kontrollere protokolunderstøttelsen.

Hvorfor kan et korrekt resultat stadig se forkert ud?

Et korrekt resultat kan være anderledes end det, du ser i browseren, fordi cacher, DNS-poster og anmodningens kontekst kan føre de to anmodninger til forskellige responser. Opslaget udføres på serveren, så det kan ramme en anden CDN-node eller registrere en nyligt ændret DNS-post tidligere eller senere end dit lokale netværk.

Browsere sender desuden deres egne cookies, accepterede indholdstyper, sprog og cachevalidatorer. En WordPress-side for brugere, der er logget ind, kan derfor returnere andre cacheregler end en anonym serveranmodning. Geografisk routing og systemer til håndtering af bots kan også variere responsen ud fra kildenetværket eller anmodningsheaderne.

Når du har ændret DNS, kan cachelagrende resolvere fortsætte med at bruge den tidligere post, indtil dens levetid udløber. Når trafikken når den nye server, kan et gammelt CDN-objekt eller browserens cache stadig returnere tidligere indhold. Kontrollér den fortolkede vært separat, ryd relevante cacher, og sammenlign den nøjagtige URL i stedet for at gå ud fra, at alle værtsnavne bruger samme konfiguration.

Ofte stillede spørgsmål

Viser opslaget også anmodningsheaderne?

Nej. Det henter de responsheadere, som URL'en returnerer ved en typisk GET-anmodning. Anmodningsheadere er de metadata, der sendes til serveren. Hvis du vil undersøge dem fuldt ud, skal du bruge browserens udviklerværktøjer, serverlogfiler eller en kommandolinjeklient.

Er de URL'er, jeg indtaster, private?

Opslaget udføres på serveren. Dine indtastede oplysninger sendes til serveren via HTTPS og gemmes ikke. Undgå at indtaste URL'er, der indeholder adgangskoder, adgangstokens eller følsomme forespørgselsparametre, da destinationsserveren også modtager disse værdier, når anmodningen sendes.

Kan HTTP-headere forklare en certifikatadvarsel?

Som regel ikke alene. TLS-forbindelsen etableres, før HTTP-responsen sendes. Et udløbet certifikat, et værtsnavn der ikke matcher, eller en udsteder der ikke er tillid til, kan derfor forhindre, at der overhovedet returneres headere. Undersøg certifikatet og dets kæde separat, hvis browseradvarslen vises, før siden indlæses.

Hvorfor får jeg flere Set-Cookie-headere?

En respons kan angive mere end én cookie, og hver cookie bruger sit eget Set-Cookie-felt. Kombinér dem ikke, som om de var en kommasepareret liste, da cookiers udløbsdatoer selv kan indeholde kommaer. Gennemgå hver cookies domæne, sti og sikkerhedsattributter separat.

Kan jeg sammenligne resultatet med curl?

Ja. En kommando som curl -D - https://example.com/ -o /dev/null udskriver responsheaderne og kasserer responsens indhold. Forskellige curl-versioner, anmodningsheadere, indstillinger for omdirigering og netværksplaceringer kan give et andet resultat. Sørg derfor for, at disse forhold er ens, før du betragter en forskel som en serverfejl.