Slå opp hvilken som helst HTTP-statuskode: hva den betyr, når servere sender den og hvilken spesifikasjon som definerer den. Søk etter nummer eller søkeord, filtrer etter klasse, og lenk direkte til en kode.
Serveren har mottatt forespørselshodene, og klienten kan sende meldingsteksten. Vises når en klient sender «Expect: 100-continue» før opplasting av en stor meldingstekst.
Serveren har godtatt en WebDAV-forespørsel, men er ikke ferdig med den ennå. Den ble fjernet fra senere WebDAV-spesifikasjoner og brukes sjelden i dag.
Sendes før det endelige svaret, slik at nettleseren kan begynne å forhåndslaste ressurser som er oppført i Link-headere. Brukes av CDN-er og servere for å gjøre sideinnlastinger raskere.
Forespørselen lyktes og opprettet en ny ressurs, vanligvis identifisert av Location-headeren. Typisk etter en vellykket POST som oppretter en oppføring.
Forespørselen lyktes, og det er ikke noe innhold å returnere. Vanlig for DELETE-forespørsler og ved lagring av data når klienten ikke trenger et svarinnhold.
Ressursen har flyttet permanent til URL-en i Location-headeren. Nettlesere og søkemotorer oppdaterer lenkene sine; noen klienter endrer POST til GET når de følger den.
Ressursen ligger midlertidig på en annen URL angitt i Location-headeren. Vanlig etter innlogging og for kortvarige viderekoblinger; nettlesere følger den vanligvis med GET.
Klienten bør hente resultatet fra en annen URL med GET. Brukes etter en skjema-POST for å viderekoble til en bekreftelsesside (mønsteret Post/Redirect/Get).
Den bufrede kopien er fortsatt gyldig, så serveren sender ingen body. Oppstår når en nettleser revaliderer en bufret fil med If-None-Match eller If-Modified-Since.
Ressursen ligger midlertidig på en annen URL, og klienten må gjenta forespørselen med samme metode og body. Brukes også av nettlesere for interne HSTS-viderekoblinger til HTTPS.
Ressursen har flyttet permanent, og klienten må bruke samme metode og body på den nye URL-en. Den permanente motparten til 307, trygg for viderekobling av POST-forespørsler.
Forespørselen mangler gyldig påloggingsinformasjon. Til tross for navnet betyr det «uautentisert»; serveren sender en WWW-Authenticate-header som beskriver hvordan man logger inn.
Serveren forsto forespørselen, men avviser den, og å logge inn på nytt vil ikke hjelpe. Oppstår når tillatelser mangler, en katalogvisning er deaktivert eller en brannmur blokkerer klienten.
Ressursen finnes, men støtter ikke HTTP-metoden som brukes, for eksempel POST til en skrivebeskyttet URL. Responsen viser tillatte metoder i Allow-headeren.
En betingelse i forespørselens headere, som If-Match, ble ikke oppfylt. Brukes for å hindre overskriving av en ressurs som endret seg etter at klienten sist leste den.
URL-en er lengre enn det serveren vil behandle. Skyldes vanligvis at et skjema sender for mye data med GET eller en omadresseringsløkke som stadig legger til parametere.
En aprilsnarr fra 1998 Hyper Text Coffee Pot Control Protocol: en tekanne som nekter å brygge kaffe. HTTP reserverer koden som ubrukt, men noen servere returnerer den som et påskeegg eller for å avvise uønskede boter.
Klienten har sendt for mange forespørsler i løpet av en gitt tid. API-er bruker den for hastighetsbegrensning og inkluderer ofte en Retry-After-header som sier når du kan prøve igjen.
Forespørselsheadere er for store, ofte på grunn av for mange eller for store informasjonskapsler. Å slette nettstedets informasjonskapsler løser vanligvis problemet.
Ikke en standardkode. nginx bruker den internt for å lukke forbindelsen uten å sende noe svar, ofte for å avvise uønsket trafikk; klienter mottar den faktisk aldri.
Ikke en standardkode. nginx logger den når klienten lukket forbindelsen før serveren svarte, for eksempel en bruker som avbryter en treg side eller en tidsavbrudd på klientsiden.
Serveren støtte på en uventet feil og kunne ikke fullføre forespørselen. En generisk feil fra en bug, krasj eller feilkonfigurasjon; serverloggene har detaljene.
En gateway eller proxy mottok et ugyldig svar fra oppstrømsserveren. Vanlig når applikasjonen bak nginx eller en lastbalanserer har krasjet eller starter på nytt.
Serveren er midlertidig ute av stand til å håndtere forespørselen fordi den er overbelastet eller nede for vedlikehold. En Retry-After-header kan angi når du bør prøve igjen.
Ikke en standardkode. Cloudflare returnerer den når opprinnelsesserveren avviste tilkoblingen, vanligvis fordi webserveren er nede eller blokkerer Cloudflares IP-adresser.
Ikke en standardkode. Cloudflare returnerer den når den ikke får kontakt med opprinnelsesserveren, for eksempel på grunn av et DNS- eller rutingsproblem.
Ikke en standardkode. Cloudflare returnerer den når den fikk kontakt med opprinnelsesserveren, men ikke mottok et HTTP-svar innen tidsavbruddet (100 sekunder som standard).
Ikke en standardkode. Cloudflare returnerer den når opprinnelsesserverens SSL-sertifikat er ugyldig og Full (strict) SSL-modus er aktivert.
Definert i Cloudflare
Slik bruker du det
Skriv inn et kodenummer (for eksempel 404 eller bare 5 for alle serverfeil) eller et søkeord som «redirect» eller «timeout».
Begrens listen med klassefilteret: informasjon, suksess, omdirigering, klientfeil eller serverfeil.
Bruk «Kopier lenke» på en hvilken som helst kode for å dele en direkte lenke til den, for eksempel i en feilrapport.
Slik fungerer det
Hvert HTTP-svar starter med en tresifret statuskode. Det første sifferet angir klassen: 1xx-informasjonssvar, 2xx-suksess, 3xx-omdirigering, 4xx-feil forårsaket av forespørselen og 5xx-feil på serversiden. Klienter som ikke gjenkjenner en bestemt kode, behandler den som x00-koden i klassen, så en ukjent 4xx-kode håndteres som 400.
De grunnleggende kodene er definert i RFC 9110 (HTTP Semantics, 2022), som erstattet den eldre RFC 7231. Andre kommer fra utvidelser: WebDAV (RFC 4918), RFC 6585 for 428, 429, 431 og 511, RFC 7725 for 451 og RFC 8470 for 425. RFC 9110 ga også nytt navn til to koder: 413 heter nå «Content Too Large» og 422 «Unprocessable Content», som du fortsatt kan se under de gamle navnene «Payload Too Large» og «Unprocessable Entity».
Noen koder du møter i logger, er ikke standarder i det hele tatt. nginx bruker 444 og 494–499 internt (499 viser en klient som ga opp å vente), og Cloudflare returnerer 520–526 når det ikke får et skikkelig svar fra opprinnelsesserveren. Disse er merket «Non-standard» i listen. Årsaksfrasene (for eksempel «Not Found») vises på engelsk slik de står i spesifikasjonene; HTTP/2 og HTTP/3 sender bare nummeret.
Eksempler
301 eller 308 når du flytter et nettsted
Begge er permanente. Bruk 301 for vanlige sideflyttinger; bruk 308 når klienter må gjenta POST- eller PUT-forespørsler til den nye URL-en, fordi noen klienter endrer POST til GET etter en 301.
401 versus 403
Et API returnerer 401 når ingen token eller en utløpt token sendes, så klienten bør logge inn. Det returnerer 403 når tokenen er gyldig, men brukeren mangler tillatelse, så det hjelper ikke å logge inn på nytt.
Diagnostisering av en 502 bak nginx
En 502 Bad Gateway fra nginx betyr at applikasjonen bak ikke svarte skikkelig. Sjekk om app-prosessen kjører og hva den logget; 504 betyr i stedet at den svarte for sakte.
Ofte stilte spørsmål
Hva er forskjellen mellom 404 og 410?
404 betyr at serveren ikke finner ressursen og sier ingenting om fremtiden. 410 sier at ressursen ble fjernet med vilje og ikke kommer tilbake, noe som hjelper søkemotorer med å fjerne URL-en raskere.
Bør en valideringsfeil returnere 400 eller 422?
Begge brukes. 400 passer for forespørsler serveren ikke kan tolke, for eksempel ødelagt JSON. 422 passer for forespørsler som tolkes riktig, men inneholder ugyldige verdier, for eksempel et e-postfelt uten @.
Er 418 I'm a teapot en ekte statuskode?
Den stammer fra en aprilsnarr-RFC fra 1998. RFC 9110 reserverer 418 som ubrukt, slik at den ikke tildeles noe annet, og noen få servere returnerer den som en spøk, men den har ingen standard betydning.
Hvor kommer 499 fra?
499 er nginx-spesifikk. Den vises i nginx-logger når klienten lukker tilkoblingen før serveren sender et svar. Klienten mottar aldri en 499; den peker vanligvis på trege svar eller tidsavbrudd på klientsiden.
Behandler søkemotorer 302 som 301?
En 302 signaliserer en midlertidig flytting, så søkemotorer beholder vanligvis den opprinnelige URL-en indeksert i begynnelsen. Hvis en 302 blir værende lenge, kan Google behandle den som en permanent omdirigering. Bruk 301 eller 308 for permanente flyttinger.
Personvern
Listen er en del av siden. Søk og filtrering skjer i nettleseren din; søkeordene dine sendes ikke noe sted og tas ikke med i analysedata.