HTTP-statuskoder: Hver mulig kode vises

Afsløring: Din support hjælper med at holde webstedet kørt! Vi tjener et henvisningsgebyr for nogle af de tjenester, vi anbefaler på denne side.


Contents

Grundlæggende om HTTP-statuskode

De fleste mennesker tænker ikke for hårdt over, hvad der faktisk sker, når de navigerer til en webside. De åbner bare deres browser, klikker på noget, og der er det på min skærm!

Leder du efter specifik kode? Se på indholdsfortegnelsen til højre!

Vi foretrækker ikke at tænke på den komplekse dans på forespørgsler og svar, der sker mellem vores computers webbrowser og en server langt væk, i et datacenter, uset (normalt) selv af webstedets systemadministrator og IT-personale.

Men derefter, nu og da, får vi en fejl. Vi får en smart 404 Not Found side med et sjovt billede. Eller vi får en tom side med en note fra vores egen browser, der fortæller os om en ukendt 501-fejl.

Som en afslappet besøgende på websitet er dette blot irriterende. Vi prøver normalt igen – opdater, gå tilbage, klik igen. Nogle gange fungerer det – vi kalder det en fejl og glemmer straks det. Nogle gange fungerer det ikke – vi kalder det “et dårligt websted” og glemmer normalt også det.

Men hvis du faktisk kører et websted – det ændrer alt. HTTP-fejlene er ikke irriterende. De er vanvittige. De er pinlige.

Hvis du er specielt teknisk kyndig, eller hvis du har et godt it-team, er det måske ikke så meget. De fleste problemer som det er let at løse. Men hvis du er en lille virksomhedsejer, kan kørsel af dit eget websted, HTTP-status og fejlkoder gøre dig vanvittig.

Hvordan løser du HTTP-fejl? Hvordan undgår du HTTP-fejl? Hvad betyder alle disse HTTP-statuskoder endda?

Det er hvad denne vejledning dækker sammen med information om:

  • gode HTTP-statuskoder (dem, du normalt ikke ser)
  • nyttige HTTP-statuskoder
  • hvilken type omdirigeringer, du skal bruge (og hvorfor).

Men først skal du forstå, hvordan HTTP fungerer i første omgang for at forstå HTTP-statuskoder.

HTTP-anmodninger og svar

HTTP står for “HyperText Transfer Protocol.”

Hvad er en protokol?

Når du går ombord på et flådeskib, er der en bestemt måde at gøre ting på. Først hilser du flaget, så hilser du betjenten, så beder du om tilladelse til at gå om bord.

Det er en protokol.

En protokol er et sæt regler for en bestemt type interaktion.

Nogle gange er en protokol meget stiv og defineret:

  • Sådan går du om bord på et skib:
    • Hilsen flag
    • Salutbetjent på vagt
    • Bed om tilladelse til at gå om bord.

Nogle gange er protokoller lidt løsere og uskrevne, men stadig velkendte:

  • Når din fødselsdagskage ankommer:
    • Vent til alle er færdige med at synge
    • Ønsk dig noget
    • Blæs stearinlysene ud, helst i et åndedrag.

Computerinteraktioner handler om protokoller. Når to computere (eller et netværk af computere) taler med hinanden, skal de have et sæt veldefinerede regler for kommunikation.

Reglerne for, hvordan din lokale computers webbrowser kommunikerer med den webserver, der er vært for det websted, du prøver at se på, er HTTP (HyperText Transfer Protocol).

Hvorfor overfører vi HyperText?

Oprindeligt var websider primært dokumenter. En “webside” blev betragtet som en faktisk “side.” Et sted var en samling af dokumenter. Startsiden for et websted var et “indeks” over de tilgængelige dokumenter.

Hvilken type dokumenter? Hypertekstdokumenter.

Hypertext betyder bare, at dokumenterne linker til hinanden med “hyperlinks.” I dag kalder vi dem bare almindelige “links” – de er så almindelige nu, at vi ikke kalder dem “hyper” mere.

Klikbare “hyper” -links i tekst – den idé, der er så almindelig nu, var så revolutionerende, da inernet først blev oprettet, at alt blev opkaldt efter det.

Sproget til forfatter af disse dokumenter? Hypertext Markup Language (HTML). Og protokollen til anmodning og modtagelse af disse dokumenter? HTTP.

Så HTTP er …

HTTP er sæt regler og procedurer for, hvordan en webbrowser (eller anden “klient”) anmoder om ressourcer fra en anden computer (“serveren”), og hvordan den anden computer reagerer på disse anmodninger.

HTTP-anmodning

Så når du skriver en adresse, klikker på et link eller på anden måde åbner en webside, sender din browser en anmodning til en anden server.

Målet for anmodningen defineres af URL’en og DNS-systemet. DNS-systemet er et emne for en anden dag, men dybest set – DNS er en adressebog, der matcher domænenavne til specifikke computer-IP-adresser.

Anmodningens mål er defineret af domænenavnet, og hele URL-adressen er den vigtigste del af anmodningen – alt efter domænenavnet fortæller serveren den specifikke ressource, der bliver anmodet om. Anmodningen indeholder også andre oplysninger som:

  • Anmodningstypen. De to mest almindelige er:
    • FÅ – “Send mig denne ressource.”
    • POST – “Her er nogle data, der skal behandles.”
  • Header Fields – Valgfrie metadatafelter, der bruges til at fortælle serveren om klienten (hvilken type browser f.eks.).
  • Organ – De data, der er sendt af klienten (til brug med POST).

Serveren får denne anmodning og sender (efter en vis behandling) et svar.

HTTP-svar

Den allerførste linje i et svar er HTTP-status.

Statuslinjen har to dele, en talekode (som 200) og en tekstforklaring (som succes).

Når alt fungerer fint, får du statusen 200: Succes (som du som en menneskelig bruger aldrig ser), derefter nogle overskriftsdata (som du heller ikke ser), og derefter den ressource, du anmodede om (hvilket er, hvad du ser ).

Ressourcen kan være en hel webside, et billede, en video, en lydfil. Det kan også være noget, du ikke kan se, f.eks. En JavaScript-fil eller et stilark.

Når ting ikke fungerer så godt, kan du muligvis se en meddelelse om status. Normalt sker det, når du får noget som en 404- eller 501-kode. Dette er fejlkoder. Noget gik galt.

Svar med fejlkoder 404 eller 501 kommer ikke tilbage med den ressource, du har anmodet om. Nogle gange kommer de tilbage med en anden ressource (som den smarte 404-side). Nogle gange er der overhovedet ingen ressource (det er når du får browserens blanke side og standardfejlmeddelelse).

Der er også statuskoder, der beder browseren om at se et andet sted, som 301-omdirigering. Disse svar kommer heller ikke den ønskede ressource.

I stedet fortæller overskridelsesdata browseren at indgive en ny anmodning med en anden URL. Man bemærker normalt ikke, når det sker, fordi din browser bare gør, hvad den får at vide, og fremsætter den anden anmodning.

Så viser det dig ressourcen fra det andet svar, uden at fortælle dig, at der er sket noget. Omdirigering af svarskoder betyder normalt ikke for slutbrugerne, men de skal have meget for webstedets administratorer.

Statuskodeklasser

Du har sandsynligvis bemærket, at alle statuskoder er trecifrede tal. Bemærkede du, at det første ciffer altid er mellem 1 og 5?

Statuskoder er grupperet i fem “klasser” af koder. Fejlen 404: Ikke fundet er en del af statuskoderne 400 (eller nogle gange 4xx). Hver klasse omfatter en bestemt række spørgsmål eller stater.

  • 1xx – Oplysende – Dette er foreløbige svar, der er beregnet til at blive brugt, mens serveren fortsætter med at behandle anmodningen. De bruges sjældent.
  • 2xx – Succes – Koder, der bruges, når ting fungerer som de skulle. Forskellige succeskoder returneres baseret på hvad specifikt anmodningen forsøgte at gøre.
  • 3xx – Omdirigering – Koder, der bruges til at fortælle klienten at lede efter den ønskede ressource et andet sted.
  • 4xx – Klientfejl – Disse koder fortæller klienten, at den gjorde noget forkert.
  • 5xx – Serverfejl – Kode til, når noget på serveren ikke fungerer som forventet.

Vi dækker de specifikke koder fra hver klasse mere dybtgående i deres egne sektioner.

Håndtering af HTTP-status (og fejl) -koder

Denne vejledning dækker alle de mulige HTTP-status- og HTTP-fejlkoder – fra den fælles til den aldrig brugt. Vi forklarer, hvad hver kode betyder, hvorfor de genereres, hvornår koden muligvis er et problem, og hvordan man håndterer problemerne.

HTTP-statuskode 1xx – Oplysende

Viden er magt. Information er befriende.

—Kofi Annan

HTTP-statuskoder i 1xx-klassen er beregnet til at være midlertidig, sendt af serveren, før der sendes et fuldt og afsluttet andet svar.

De blev introduceret i HTTP / 1.1, så tidlige browsere, der implementerer HTTP / 1.0, ikke kan håndtere dem, og servere bør ikke afslutte 1xx-koder i disse tilfælde.

HTTP 100 Fortsæt

En anmodning-svar-sekvens er typisk ligetil. En enkelt anmodning fremsættes, modtages og besvares.

Men nogle gange skal en anmodning opdeles i dele. Dette kan forekomme, hvis anmodningen er for stor. Det kan forekomme, hvis rekvirenten skal kontrollere, om header er formateret korrekt, eller hvis serveren faktisk er klar til at modtage anmodningen.

I disse tilfælde sender klienten (browseren) muligvis den første anmodning med en header, der inkluderer Forvent: 100-fortsættelse.

Når dette sker, vil serveren modtage den første anmodning og – hvis alt er i orden – svare med status 100: Fortsæt. Dette signaliserer klienten til at gennemføre anmodningen.

Hvis alt ikke fungerer ok, sender serveren en 417 forventning mislykket.

HTTP 101 switching protocols

En klient kan bede en server om at skifte protokoller, for eksempel fra HTTP / 1.1 til HTTP / 2.0.

Hvis serveren er villig til at imødekomme denne anmodning, sender den svaret 101: Skift af protokoller tilbage med overskriftsdata, der inkluderer navnet på den nye protokol, der bruges.

HTTP 102-behandling

Denne kode bruges kun med WebDAV, som er en udvidelse af HTTP, der giver filmanipuleringsevne, noget ligner FTP (skønt meget forskellig i faktisk implementering).

En WebDAV-anmodning kan indeholde en masse underanmodninger. 102: Behandlingsstatus lader klienten vide, at serveren modtog anmodningen og arbejder på den, men stadig har et arbejde at gøre. Dette forhindrer klienten i at antage, at anmodningen var gået tabt og udløb.

HTTP-statuskode 2xx – succes

Alt hvad du har brug for i dette liv er uvidenhed og selvtillid, og så er succes sikker.

—Mark Twain

HTTP-statuskoder i 2xx-klassen er beregnet til at blive brugt, når en anmodning er afsluttet som tilsigtet.

Mange af disse koder bliver aldrig, eller sjældent, faktisk brugt eller endda implementeret.

HTTP 200 OK

Dette er standardsvaret for vellykkede anmodninger – det er den statuskode, du normalt ønsker og forventer.

Når anmodningen er GET (beder om en ressource), vil svaret omfatte ressourcen. Når anmodningen er en POST (eller anden type), vil svaret indeholde en ressource, der beskriver eller indeholder resultatet af handlingen.

HTTP 201 Oprettet

Nogle anmodninger er beregnet til at oprette en ny ressource. Når disse er fuldført, sendes 201-status for at indikere, at den nye ressource er oprettet. Dette bruges normalt sammen med PUT-anmodningstypen.

HTTP 202 accepteret

Anmodningen er blevet accepteret, men ikke efterkommet. Anmodningen kan eller måske ikke reageres.

HTTP 203 Ikke-autoritativ information

Svaret indeholder den ønskede ressource, men ressourcen kan være hentet fra en anden kilde og kan derfor være upålidelig – serveren garanterer ikke for ressourceens gyldighed eller ægthed.

HTTP 204 Intet indhold

Dette sendes, når serveren har behandlet anmodningen med succes, men behøver ikke at returnere noget indhold. Oftest sker dette som et resultat af en SLET-anmodning.

Når der sendes en 204-anmodning, skal brugeragenten (klienten eller webbrowseren) specifikt ikke ændre visningen.

Hvis for eksempel anmodningen blev sendt via en formular på en side, skal svaret ikke forårsage, at formularen opdateres, eller at browseren besøger en anden side – der er ikke nyt indhold i anmodningen om at erstatte det eksisterende indhold i brugerens udsigt.

HTTP 205 Nulstil indhold

205-svaret ligner en 204, men brugeragenten skal opdatere deres syn på standardtilstanden for det aktuelle dokument.

HTTP 206 delvis indhold

Dette bruges, når serveren kun sender en del af den anmodede ressource, fordi brugeren anmodede om kun at modtage en del af ressourcen.

Dette sker, når en ressource er stor nok eller forbindelsen upålidelig nok, at brugeragenten ønsker at opdele ressourcen i en serie af “chunked” anmodninger, som illustreret:

  • Klient: Giv mig den første 1/4.
    • Server: 206 Delvis indhold
  • Klient: Giv mig den anden

    1/4.

    • Server: 206 Delvis indhold.
  • Og så videre…
    • …og så videre.

Disse delvise anmodninger fremsættes af klienten ved hjælp af rækkehovedet. De forekommer muligvis den ene efter den anden (for at beskytte mod downloadfejl) eller alt på én gang i flere tråde (for at fremskynde download).

HTTP 207 Multi-Status

Ligesom 103 bruges dette kun med WebDAV.

En WebDAV-anmodning kan have flere underanmodninger, der hver har sin egen status og respons. 207-status angiver, at responsen skal indeholde et XML-dokument, der indeholder status og svar på hver underanmodning.

HTTP 208 Allerede rapporteret

En anden status for WebDAV-kun. Dette betyder, at medlemmerne af en DAV-binding allerede er opregnet i et tidligere svar på den aktuelle anmodning og ikke medtages igen.

HTTP 226 IM brugt

Serveren har opfyldt en anmodning om ressourcen, og svaret er en repræsentation af resultatet af en eller flere instansmanipulationer anvendt på den aktuelle instans.

HTTP-statuskode 3xx – omdirigering

Hver gang du opgiver noget, skal du erstatte det med noget.

—Lou Holtz

Statusser i klassen 3xx sendes, når der kræves yderligere handling fra klientens side for at afslutte anmodningen. Dette bruges mest til omdirigering af en URL til en anden, dog ikke altid.

I tilfælde af GET-anmodninger udfører browseren generelt den anden anmodning uden input eller yderligere interaktion fra brugeren. I andre tilfælde kræves yderligere brugerintervention.

For at undgå uendelige omdirigeringssløjfer vil browsere typisk ikke følge mere end fem på hinanden følgende omdirigering af den samme anmodning.

HTTP 300 flere valg

300-status returneres af browsere, når anmodningen resulterer i flere indstillinger for ressourcen. I teorien kunne dette bruges til at præsentere forskellige filformatmuligheder, forskellige mediepræsentationer af det samme indhold eller endda ordfornemmelse.

300 Multiple Choice-status har et stort potentiale, men bruges ikke ofte.

HTTP 301 flyttes permanent

Denne status angiver, at ressourcen har ændret URL permanent.

Søgemaskiner opdaterer deres indeks baseret på dette, tildeler normalt enhver placering fra den originale URL til den nye URL.

Browsere og andre typer klienter cacher ofte den nye URL og følger automatisk omdirigerings-URL’en uden direkte at kontrollere originalen for efterfølgende anmodninger, selvom den originale URL manuelt leveres. Gemte bogmærker opdateres også typisk.

Generelt, hvis du opretter omdirigeringer på grund af en ændring i domænenavnet til URL-strukturen, skal du bruge 301: Flyttet Permanent omdirigeringer.

Disse kan konfigureres i filen .htaccess eller httpd.conf på din server eller ofte i dit indholdsstyringssystem. (For eksempel er der flere WordPress-plugins til styring af 301 omdirigeringer.)

Når et websted omdesignes og en URL-struktur ændres, er det meget vigtigt at konfigurere en 301-omdirigering for hver URL fra det originale websted. Undladelse af dette vil medføre ødelagte links og skuffede besøgende.

HTTP 302 fundet

302-statuskoden bruges ofte til midlertidige omdirigeringer. Industripraksis med 301 omdirigeringer har varieret fra den originale specifikation, og specifikationen har udviklet sig til at imødekomme industriens praksis.

Oprindeligt anførte specifikationen, at en 302-status skulle få browseren til at indgive en anden, identisk anmodning om den nye URL. Imidlertid implementerede mange første generations webbrowsere det på en sådan måde, at POST-anmodninger blev omskrevet som GET-anmodninger.

For at forsøge at afklare situationen tilføjede den opdaterede specifikation HTTP / 1.1 to yderligere statuskoder, 303 og 307.

302 Fundet skulle efterligne den “skifte til GET” -adfærd, der var implementeret, mens 307 Midlertidig omdirigering var beregnet til at erstatte den oprindelige 302 forventede opførsel.

De fleste servere og webrammer fortsatte imidlertid simpelthen at bruge 302 til bagudkompatibilitet med browsere, der ikke implementerer de nyere standarder.

Senere HTTP-specifikationer erhvervet til standard praksis, hvilket giver browsere mulighed for at omskrive POST-anmodninger til GET-anmodninger.

Konsekvensen af ​​alt dette er, at hvis du bruger en 302-omdirigering på en URL, der skulle acceptere POST-data, vil disse data sandsynligvis ikke blive inkluderet i den anden anmodning.

Af denne grund bør 302 kun bruges på webadresser, der accepterer POST-data (webformularer), hvis serveren faktisk kan acceptere de indsendte data på den oprindelige URL, og bruge omdirigeringen til at levere en side, efter at dataene er blevet accepteret.

Alt dette gør i praksis 303 overflødige.

Generelt bør en 302-omdirigering ikke bruges

HTTP 303 Se Andet

I praksis er dette identisk med en 302-status. Det betyder, at svaret eller ressourcen kan findes på en anden URL ved hjælp af GET-metoden. Når den modtages som svar på en POST-anmodning, skal browseren antage, at dataene er modtaget.

HTTP 304 ikke ændret

Webbrowsere kan sende en anmodning med en header, der spørger, om en ressource er blevet ændret siden en bestemt data og tid. Dette gøres, hvis browseren allerede har downloadet ressourcen tidligere og gemt den.

Hvis den er blevet ændret siden det tidspunkt, svarer serveren med ressourcen og en 200 succes-status.

Hvis ressourcen imidlertid ikke er blevet ændret, sender serveren status 304 Ikke ændret og sendes heller ikke ressourcen. Browseren skal derefter tjene den gemte version af ressourcen, da den ikke er ændret.

HTTP 305 Brug proxy

Den anmodede ressource er kun tilgængelig via en proxy. Proxy-adressen er angivet i svaret. Webbrowser forventes at prøve igen anmodningen via proxy. Ikke alle klienter implementerer dette i henhold til standarden på grund af sikkerhedsmæssige årsager.

HTTP 306 switch proxy

Status 306 betød oprindeligt “Efterfølgende anmodninger skal bruge den specificerede proxy.” Den er ikke længere i brug.

HTTP 307 Midlertidig omdirigering

Denne status blev oprettet for at gentage den oprindelige intention med 302-status (se ovenfor).

Status 307: Midlertidig omdirigering betyder, at anmodningen skal gentages denne gang med en anden URL, men at anmodninger i fremtiden dog stadig skal bruge den originale URL.

I modsætning til, hvordan 302 historisk er blevet implementeret af klienter, bør anmodningsmetoden ikke ændres, når du sender den anden anmodning. For eksempel skal en POST-anmodning gentages ved hjælp af en anden POST-anmodning og med alle originale POST-data inkluderet.

HTTP 308 Permanent omdirigering

Den aktuelle anmodning skal gentages ved hjælp af en anden URL, og alle fremtidige anmodninger skal også sendes til den URL.

Ligesom 307 og 302 duplikerer denne status funktionaliteten, der er specificeret i den originale specifikation af 301. Med 308 skal (dog med 307) den anden anmodning være identisk med den originale anmodning – ved hjælp af den samme metode og indeholde de samme data.

HTTP 308 CV ufuldstændig

Denne statuskode blev oprettet og bruges af Google. Det er en del af det genoptagelige HTTP-anmodningsforslag og bruges til at genoptage aborterede PUT- eller POST-anmodninger.

HTTP-statuskode 4xx – Klientfejl

Enhver kan begå fejl, men kun en idiot vedvarer ved en fejl.

—Marcus Tullius Cicero

Af de fem klasser af HTTP-statuskoder er kun to af dem virkelig “Fejlkoder”, 4xx og 5xx klasser.

4xx-serien med HTTP-fejl er beregnet til at blive brugt, når fejlen ser ud til at komme fra klienten – det vil sige, der er noget galt med anmodningen.

Sammen med fejlstatus og anden headerinformation giver servere ofte et komplet svar (kaldet en “enhed” i stedet for “ressource”, men ellers det samme), som antages at vises til brugeren.

Dette er beregnet til at give brugeren en måde at løse uanset klientfejlen. Den mest almindelige set form af disse enheder er siden 404, der diskuteres nedenfor.

HTTP 400 dårlig anmodning

Dette er et generisk svar på en anmodning med et eller andet problem. Problemet kan være en misdannet syntaks, ugyldig formatering eller vildledende anmodningsdirigering. Servere vil ofte give yderligere oplysninger om, hvad der specifikt gik galt med anmodningen.

HTTP 401 Uautoriseret

Dette bruges, når ressourcen er begrænset til bestemte godkendte brugere. Status betyder, at der ikke har været nogen godkendelse, eller at godkendelsen mislykkedes. I henhold til standarden skal et svar med denne kode indeholde et middel til autentificering.

HTTP 402 betaling krævet

Ikke almindeligt anvendt, da specifikationen ikke giver tilstrækkelig information til en aktuel implementering (den er navngivet og reserveret til fremtidig brug, men en fuld specifikation er ikke blevet vedtaget).

Hensigten er at bruge denne kode som en del af en eller anden type digital kontant- eller mikropaymentsystem.

YouTube bruger denne status, hvis de modtager for mange anmodninger fra en enkelt IP-adresse. Svaret kræver en CAPTCHA for at verificere, at brugeren er et menneske.

HTTP 403 forbudt

I lighed med 401 betyder det, at anmodningen var gyldig, men serveren vil ikke svare på den, fordi brugeren ikke har tilladelse til at se ressourcen. I modsætning til en 401: Uautoriseret fejl, vil autentificering ikke gøre nogen forskel.

HTTP 404 ikke fundet

Dette er den mest almindelige set 4xx-klassefejl, og måske den mest hyppigt bemærkede HTTP-status for den gennemsnitlige bruger.

404 returneres, hvis anmodningen er gyldig, men den anmodede ressource kan simpelthen ikke findes på serveren.

De fleste webrammer giver webstedsadministratoren muligheden for at oprette en “404-side.” Dette er en side, som brugeren ser, når der opstår en 404-fejl.

Dette informerer typisk brugeren om problemet, undskylder ulejligheden og giver alternative måder at finde det indhold, som brugeren leder efter, såsom søgning.

Nogle websteder vil se på alle nøgleord i anmodnings-URL’en og forsøge at bestemme, hvilken side eller ressource brugeren måske har været på udkig efter og give en eller flere muligheder for alternative sider.

Selvom 4xx-fejl teknisk set er “Klientfejl”, er 404-fejlen ofte et resultat af døde links – URL’er, der tidligere havde indhold, men som nu er ændret.

Af denne grund kan det være lidt pinligt at skulle levere en 404-side for websteder, da det ofte betyder en manglende levering af korrekt URL-omdirigering. Implikationen er ikke “du har rodet din anmodning”, men snarere “vi mistede den ting, du leder efter.”

På grund af dette er det meget almindeligt, at websteder forvandler deres 404 sider til et sted for humor.

HTTP 405-metode er ikke tilladt

Dette bruges, når anmodningen er velformet, og den ressource, den beder om, findes, men anmodningsmetoden (f.eks. GET eller POST) er ikke passende til ressourcen.

F.eks. Skal en URL, der modtog formulardata, få adgang til med en POST-anmodning. En GET-anmodning kan resultere i et svar på 405: Metode ikke tilladt. Brug af PUT på en skrivebeskyttet ressource kan også forårsage en sådan reaktion.

HTTP 406 Ikke acceptabel

Anmodninger kan og ofte også angive den type indhold, de leder efter, ved hjælp af MIME-typer.

Hvis den anmodede ressource er af en type, der ikke svarer til den eller de type (r), der er anført i anmodningens Accept-header, returnerer serveren 406: Ikke acceptabel fejl.

HTTP 407 Proxy-godkendelse påkrævet

Før klienten får adgang til den ønskede ressource, skal klienten først autentificere sig med den proxy, der er angivet i svaret.

HTTP 408 Anmod om timeout

Denne fejl opstår, når serveren afbrydes, mens den venter på anmodningen.

Fra specifikationen:

Klienten fremsatte ikke en anmodning inden for det tidspunkt, hvor serveren var parat til at vente. Klienten KAN gentage anmodningen uden ændringer på et senere tidspunkt.

HTTP 409 konflikt

Angiver, at anmodningen ikke kunne behandles, fordi den er i konflikt med sig selv. Dette kan for eksempel forekomme i tilfælde af flere opdateringer, der forårsager redigeringskonflikter med hinanden.

HTTP 410 borte

Denne fejl ligner 404-fejlen, men er beregnet til at indikere, at den anmodede ressource er blevet fjernet med vilje og vil ikke længere være tilgængelig på nogen URL.

Kunder skal reagere på dette svar ved at rense ressourcen – bogmærker skal slettes, og søgemaskiner skal fjerne ressourcen fra deres indeks.

De fleste brugssager kræver ikke dette, og 404 er normalt en mere passende fejl.

HTTP 411 Længde krævet

Den anmodede ressource kræver, at anmodninger angiver deres længde, og anmodningen gjorde det ikke.

HTTP 412-betingelse mislykkedes

Rekvirenten anbragte forudsætninger eller krav i anmodningens header, og serveren kan ikke opfylde et eller flere af disse krav.

HTTP 413 Anmod om enhed for stor

Anmodningen er større, end serveren er i stand til at behandle.

HTTP 414 Anmodning-URI for lang

Den angivne URI (URL) var for lang til, at serveren kunne behandles.

Dette er ofte årsag, når en upassende mængde data overføres inden for URL’en som en forespørgselsstreng i en GET-anmodning. Det sædvanlige middel er at konvertere anmodningen til et POST og placere dataene i kroppen af ​​anmodningen.

HTTP 415 Medietype, der ikke understøttes

Dette bruges normalt til fil uploads, når anmodningsenheden (filen der uploades) er af en type, der ikke understøttes af serveren.

HTTP 416 anmodet rækkevidde Ikke tilfredsstillende

Dette returneres, når anmodningen beder om en del af filen ved hjælp af rækkehovedet, men den anmodede del findes ikke. For eksempel, hvis anmodningen beder om en del af filen, der er længere end slutningen af ​​filen.

HTTP 417 forventning mislykkedes

Denne status returneres af en server, hvis den ikke kan imødekomme forventningen, der er indstillet af forventningsoverskriften i anmodningen.

Forventningshovedet bruges oftest til at bede serveren om en status 100 Fortsæt.

HTTP 418 Jeg er en tekande

Denne fejlkode returneres af internetforbundne tepotter, i tilfælde af at de får en anmodning om kaffe.

HTTP 419 Autentificering Timeout

Dette er faktisk ikke en del af HHTP-standarden, men nogle klienter og servere bruger den. Den returneres, når en anmodning, der kræver en godkendt bruger, sendes af en ansøger, hvis godkendelse er udløbet.

HTTP 420-metodefejl (Spring Framework)

Ikke en del af HTTP-standarden, men defineret af Spring i deres webramme, til brug når en metode mislykkedes. Det afskrives.

HTTP 420 Forbedr din ro (Twitter)

Ikke en del af HTTP-standarden, men introduceret af Twitter. Dette blev brugt af version 1 af deres API, når anmodninger fra en bestemt klient blev taksebegrænset.

Den mere standardstatus for en sådan situation er 429: For mange anmodninger.

HTTP 421 Fejlagtig anmodning

Denne status blev introduceret i HTTP / 2. Den bruges, når anmodningen blev rettet mod en server, der ikke i øjeblikket er i stand til at producere et svar.

HTTP 422 uforarbejdelig enhed

Dette er relateret til WedDAV-udvidelsen. Det returneres, når semantiske fejl gør anmodningen uforarbejdelig.

HTTP 423 låst

Brugt med WedDAV. Det betyder, at den anmodede ressource er låst.

HTTP 424 Mislykket afhængighed

Brugt med WebDav. Anmodningen mislykkedes, fordi en tidligere anmodning, som den aktuelle anmodning er afhængig af, mislykkedes.

HTTP 426 opgradering krævet

Klienten skal skifte til en anden protokol, som specificeret i opgraderingshovedet.

HTTP 428 forudsætning krævet

Dette bruges, når serveren kræver, at anmodningen er betinget.

F.eks. Kan serveren kræve, at anmodningen indeholder en betingelse, at anmodningen kun skal behandles, hvis ressourcen ikke er blevet opdateret siden en bestemt dato og tid. Hvis der ikke er angivet nogen betingelse, mislykkes anmodningen, og denne status returneres.

I henhold til specifikationen var denne status beregnet til at forhindre “problemet med” mistet opdatering “, hvor en klient GETs en ressource tilstand, ændrer den og Sætter den tilbage til serveren, når en tredjepart i mellemtiden har ændret staten på serveren , der fører til en konflikt. ”

HTTP 429 for mange anmodninger

Klienten (normalt som defineret af IP-adresse) har sendt for mange anmodninger inden for en bestemt periode.

HTTP 431 Anmod om overskriftsfelter for store

Dette returneres, når et enkelt headerfelt, eller dem alle samlet, er for stort til, at serveren kan behandles.

HTTP 440 login-timeout (Microsoft)

Ikke en del af standarden, men brugt af Microsoft. Angiver, at sessionen er udløbet.

HTTP 444 Intet svar (Nginx)

Ikke en del af standarden. Ikke faktisk en svarstatus som brugt.

Dette blev introduceret af Nginx for deres serverlogfiler for at indikere, hvornår serveren simpelthen ikke sendte et svar og lukkede forbindelsen, normalt i tilfælde af et mistænkt malwareangreb.

HTTP 449 Prøv igen med (Microsoft)

Ikke en del af standarden, men brugt af Microsoft.

Anmodningen skal gentages efter udførelse af handlingen beskrevet i svaret.

HTTP 450 blokeret af Windows Forældrekontrol (Microsoft)

Ikke en del af standarden, men brugt af Microsoft.

Denne fejl gives, når Windows Forældrekontrol er slået til og blokerer adgangen til den givne webside. Fejlen stammer fra WPC-applikationen, ikke serveren.

HTTP 451 utilgængelig af juridiske grunde (udkast)

Denne status er ikke en del af standarden endnu, men er tilgængelig i udkast.

Den tilsigtede anvendelse er til, når en ressource ikke kan leveres på grund af censur eller andre juridiske grunde. Kodenummeret er en henvisning til bogen Farenheit 451.

HTTP 451 omdirigering (Microsoft)

Ikke en del af standarden, men brugt af Microsoft. Findes i Exchange ActiveSync, hvis der enten er en mere effektiv server at bruge, eller serveren ikke kan få adgang til brugernes postkasse.

HTTP 494 Anmod om overskrift for stor (Nginx)

Ikke en del af standarden, men blev brugt af Nginx. Nu udskrevet.

Dette havde den samme betydning som 431, men blev indført før denne status var en del af HTTP-standarden.

HTTP 495 Cert Error (Nginx)

Ikke en del af standarden. Faktisk ikke en svarstatus som brugt, men vises i Nginx-logfiler, når der opstår en SSL-klientcertifikatsfejl.

HTTP 496 Intet Cert (Nginx)

Ikke en del af standarden. Faktisk ikke en svarstatus som brugt, men vises i Nginx-logfiler, når klienten ikke leverede certifikat.

HTTP 497 HTTP til HTTPS (Nginx)

Ikke en del af standarden. Faktisk ikke en svarstatus som brugt, men vises i Nginx-logfiler, når almindelige HTTP-anmodninger sendes til HTTPS-port.

HTTP 498 token udløbet / ugyldigt (Esri)

Returneret af ArcGIS for Server. En kode på 498 angiver et udløbet eller på anden måde ugyldigt token.

HTTP 499 Client Closed Request (Nginx)

Ikke en del af standarden. Faktisk ikke en svarstatus som brugt, men vises i Nginx-logfiler, når forbindelsen er blevet lukket af klienten, mens serveren stadig behandler sin anmodning, hvilket gør serveren ude af stand til at sende en statuskode tilbage.

HTTP 499 token krævet (Esri)

Returneret af ArcGIS for Server. En kode på 499 angiver, at et token er påkrævet (hvis der ikke blev indsendt et token).

HTTP-statuskode 5xx – Serverfejl

Jeg er faktisk forbløffet, når jeg overvejer, hvor svagt mit sind er, og hvor tilbøjeligt til fejl.

—Rene Descartes

Sammen med 4xx-serien er 5xx-klassen af ​​HTTP-statuskoder fejlkoder, der udstedes, når noget går galt. 5xx-fejlkoder er serverfejlkoder, hvilket betyder, at de returneres, når problemet er på serveren, i stedet for med klienten.

Når det er muligt, skal serveren returnere en svarenhed, der beskriver fejlen til klienten. Brugeragenter (webbrowsere) skal vise disse oplysninger til brugeren.

HTTP 500 intern serverfejl

Dette er den mest generelle serverfejl og udstedes af webservere, når noget ubestemt gik galt.

Generelt skal enhver ændring af en webside- eller serverkonfiguration efterfølges af grundig test for at sikre, at en 500: Intern serverfejl ikke er produceret.

Når der produceres en 500-fejl, kan det ofte hjælpe med at bestemme, hvor fejlen kommer fra at se på serverlogfilerne. Det kan ofte være så simpelt som typografiske fejl i .htaccess-filen.

HTTP 501 Ikke implementeret

Dette returneres, når HTTP-anmodningsmetoden (såsom PUT eller DELETE), API-metoden i nogle tilfælde endnu ikke er implementeret. Dette bruges til webservices API’er. Normalt er implikationen af ​​en 501-fejl, at anmodningsmetoden er planlagt til fremtidig implementering.

HTTP 502 Bad Gateway

Dette sker, når serveren fungerer som en proxy eller gateway og modtager et ugyldigt svar fra opstrømsserveren.

HTTP 503-service ikke tilgængelig

Serveren er i øjeblikket ikke tilgængelig. For eksempel fordi det er overbelastet eller ned til vedligeholdelse.

Betydningen af ​​en 503-fejl er, at strømafbrydelsen er midlertidig.

HTTP 504 Gateway Timeout

Denne fejl returneres, når serveren optrådte som en proxy eller gateway, og ikke modtager et svar fra opstrømsserveren inden for den tildelte tid.

HTTP 505 HTTP-version understøttes ikke

Denne fejl betyder, at serveren ikke understøtter den HTTP-protokollversion, der blev brugt i anmodningen.

HTTP 506-variant forhandler også

For at forstå 506-fejlen skal du forstå gennemsigtig forhandling af indhold.

Ved indholdsforhandling kan en enkelt URL levere den samme ressource eller information i flere formater. For eksempel kan det samme billede blive kodet som en JPEG og som en GIF.

Fejlen 506 opstår, når denne indholdsforhandling forårsager en løkke. For eksempel: Den ønskede ressource A har to variationer – B og C. Begge disse har A som en variant.

For at sætte det på mere teknisk sprog beskriver specifikationen 506-fejlen med:

Transparent indholdsforhandling for anmodningen resulterer i en cirkulær reference.

HTTP 507 utilstrækkelig lagerplads (WebDAV; RFC 4918)

Denne status bruges WebDAV-protokollen. Den returneres, når serveren ikke kan gemme den repræsentation, der er nødvendig for at fuldføre anmodningen.

HTTP 508 Loop Detected

Serveren stødte på en uendelig sløjfe, mens han forsøgte at tjene den ønskede ressource.

HTTP 509 båndbreddegrænse overskredet (Apache)

Ikke en del af HTTP-standarden, men introduceret og brugt af Apache. Det udstedes, når grænserne for serverbåndbredde er overskredet.

HTTP 510 ikke udvidet

Denne fejl betyder, at yderligere udvidelser af anmodningen er påkrævet for at serveren kan opfylde den.

HTTP 511 netværksgodkendelse kræves

Fejlen 511 returneres, når klienten skal autentificere for at få netværksadgang.

Denne status er beregnet til brug, når der opfanges proxies, der bruges til at kontrollere adgangen til netværket – det vil sige “Captive Portals”, der bruges til at kræve login eller servicevilkår, før de giver adgang til internettet via en WiFi-portal.

(Hvis du nogensinde har forsøgt at komme online i en lufthavn eller hotel, har du sandsynligvis fundet 511-fejlen.)

HTTP 520 ukendt fejl

Denne fejlkode er ikke en del af HTTP-standarden, men bruges af flere store udbydere af serverinfrastruktur-som-en-service, sådan en CloudFlare. Den bruges som en generel “catch-all” -fejl til uidentificerede problemer, der resulterer i, at en anmodning ikke udfyldes.

HTTP 598 Netværkslæsning Timeout-fejl (Microsoft)

Denne fejlkode er ikke en del af HTTP-standarden, men bruges af Microsoft HTTP-proxies til at signalere en timeout for netværkslæsning bag proxy til en klient foran proxy.

HTTP 599 Network Connect Timeout-fejl (Microsoft)

Denne fejlkode er ikke en del af HTTP-standarden, men bruges af Microsoft HTTP-proxies til at signalere en timeout for netværksforbindelse bag proxy til en klient foran proxy.

Ressourcer

  • IANA: webstedet for Internet Assign Numbers Authority.
  • HTTP-statuskoderegistrering: den officielle IANA-side med links til RFC’er for hver kode.

Yderligere læsning

Vi har flere guider, tutorials og infografik relateret til webudvikling:

  • Er det nede? Statussider for 50 topudbydere: selv de bedste servere går ned fra tid til anden. Denne artikel indeholder en liste over statussider for 50 af de bedste hostingfirmaer.
  • Netværksprogrammering med internetstik: Hvis du vil lære hard core netværk, er dette artiklen for at komme i gang.
  • Den ultimative liste over webmasterværktøjer A-Z: fra kodning til hosting til marketing, denne artikel har det hele.

Ultimate guide til webhosting

Se vores ultimative guide til webhosting. Det vil forklare alt hvad du har brug for at vide for at træffe et informeret valg.

Ultimate guide til webhosting
Ultimate guide til webhosting

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map