Lista över HTTP-statuskoder
HTTP -statuskoden är en del av den första raden i serversvaret för HTTP -förfrågningar . Det är ett tresiffrigt decimaltal. Den första siffran anger statusklassen . Svarskoden följs vanligtvis av en mellanslagsseparerad förklarande fras på engelska, som förklarar för personen orsaken till ett sådant svar. Exempel:
- 201 Skapad .
- 401 Obehörig .
- 507 Otillräcklig lagring .
Kunden lär sig av svarskoden om resultatet av sin förfrågan och bestämmer vilka åtgärder som ska vidtas härnäst. Uppsättningen av statuskoder är en standard och de beskrivs i relevanta RFC- dokument . Införandet av nya koder bör endast ske efter samråd med IETF . Det finns dock två kända koder som används som inte nämns i RFC: 449 Retry With. Också nämnt är den förklarande frasen "Svara med" [1] i specifikationen för WebDAV i Microsoft Developer Network introducerad av Microsoft och 509 Bandwidth Limit Exceededintroducerad i cPanel .
Klienten kanske inte känner till alla statuskoder, men den måste svara enligt kodklassen. Det finns för närvarande fem klasser av statuskoder.
Internet Information Services webbserver i sina loggfiler, förutom standardstatuskoder, använder underkoder, skriver dem med en prick efter den huvudsakliga. Samtidigt placeras inte denna underkod i svar från servern - den behövs av serveradministratören så att han mer exakt kan fastställa källorna till problem.
Granskningslista
Följande är en översiktslista över alla svarskoder som beskrivs i den här artikeln:
Beskrivning av koder
Informationsinformation
Denna klass innehåller koder som informerar om överföringsprocessen. När du arbetar genom protokollversion 1.0 bör meddelanden med sådana koder ignoreras. I version 1.1 måste klienten vara beredd att acceptera denna meddelandeklass som ett normalt svar, men servern behöver inte skicka något. Meddelanden från själva servern innehåller endast svarsstartraden och, om så krävs, några svarsspecifika rubrikfält. Proxyservrar bör skicka sådana meddelanden vidare från servern till klienten.
- 100 Fortsätt - Servern är nöjd med den initiala informationen om begäran, klienten kan fortsätta att skicka rubriker. Introducerad i HTTP/1.1.
- 101 Switching Protocols - Servern uppfyller klientens begäran och växlar protokoll enligt indikationen i rubrikfältet Upgrade. Servern skickar ett svarshuvud Upgradesom anger vilket protokoll den har bytt till. Introducerad i HTTP/1.1.
- 102 Bearbetning - Förfrågan accepterades, men det kommer att ta lång tid att behandla den. Används av servern för att förhindra klienten från att avsluta anslutningen på grund av en timeout. Klienten måste, när han tar emot ett sådant svar, återställa timern och vänta på nästa kommando i normalt läge. Dök upp i WebDAV .
- 103 Tidiga tips - Används för att returnera en del av rubrikerna tidigt när fullständiga svarsrubriker inte kan bildas snabbt.
Framgång
Meddelanden från denna klass informerar om fall av framgångsrikt godkännande och bearbetning av en kundförfrågan. Beroende på status kan servern även skicka rubriker och en meddelandetext.
- 200 OK - lyckad begäran. Om någon data efterfrågades av klienten, finns den i rubriken och/eller brödtexten i meddelandet. Introducerad i HTTP/1.0.
- 201 Skapad - En ny resurs skapades som ett resultat av en lyckad begäran. Servern KAN ange adresserna (det kan finnas fler än en) för den skapade resursen i svaret, med den föredragna adressen som anges i Location. Servern rekommenderas att i svarskroppen indikera egenskaperna för den skapade resursen och dess adress, formatet för svarskroppen bestäms av rubriken Content-Type. Vid behandling av en begäran måste en ny resurs skapas innan svaret skickas till klienten, annars ett svar med kod 202. Introducerad i HTTP/1.0.
- 202 Accepted - Begäran godkändes för behandling, men den fullföljdes inte. Klienten behöver inte vänta på den slutliga överföringen av meddelandet, eftersom en mycket lång process kan startas. Introducerad i HTTP/1.0.
- 203 Icke-auktoritativ information - liknar 200, men i det här fallet togs inte informationen som överförs från den primära källan (säkerhetskopia, en annan server, etc.) och kan därför inte vara uppdaterad. Introducerad i HTTP/1.1.
- 204 Inget innehåll - Servern bearbetade begäran, men endast rubriker skickades i svaret utan meddelandetext. Klienten behöver inte uppdatera innehållet i dokumentet, men kan applicera mottagen metadata på det . Introducerad i HTTP/1.0.
- 205 Återställ innehåll - Servern ålägger klienten att återställa data som användaren matat in. Servern överför inte meddelandets brödtext och dokumentet behöver inte uppdateras. Introducerad i HTTP/1.1.
- 206 Partiellt innehåll - Servern slutförde framgångsrikt en partiell GET-begäran och returnerade endast en del av meddelandet. I rubriken Content-Rangeanger servern innehållets byteintervall . När du arbetar med sådana svar bör särskild uppmärksamhet ägnas åt cachelagring. Introducerad i HTTP/1.1. ( mer... )
- 207 Multi-Status - servern överför resultaten av flera oberoende operationer samtidigt. De placeras i själva meddelandetexten som ett XML- dokument med en multistatus. Det rekommenderas inte att placera statusar från serien i detta objekt på grund 1xxav meningslösheten och redundansen. Dök upp i WebDAV .
- 208 Redan rapporterade - DAV-bindande medlemmar har redan listats i föregående del (multistatus) av svaret och ingår inte igen.
- 226 IM används - rubriken A-IMtogs emot från klienten och servern returnerar innehållet, med hänsyn till de angivna parametrarna. Introducerad i RFC 3229 för att utöka HTTP-protokollet med stöd för deltakodning .
Omdirigering
Koder i den här klassen talar om för klienten att ytterligare en begäran måste göras för att operationen ska lyckas, vanligtvis vid en annan URI . Av den här klassen hänvisar fem koder 301, 302, 303, 305och 307direkt till omdirigeringar. Adressen som klienten ska göra en begäran till anges av servern i Location. Detta gör att fragment kan användas i mål-URI.
Enligt de senaste standarderna kan klienten endast omdirigera utan att fråga användaren om den andra resursen begärs med hjälp av metoden GETeller HEAD[7] . Tidigare specifikationer sa att för att undvika rundresor bör användaren tillfrågas efter den 5:e omdirigeringen i följd [16] . För alla omdirigeringar, om förfrågningsmetoden inte var HEAD, bör ett kort hypertextmeddelande med destinationsadressen inkluderas i svarskroppen, så att användaren kan navigera själv i händelse av ett fel.
HTTP-utvecklare noterar att många klienter, när de omdirigerar med koder 301och 302felaktigt tillämpar metoden GETpå den andra resursen, trots att den första begäran var med en annan metod (oftast PUT) [17] . För att undvika missförstånd introducerade HTTP/1.1 koder 303och 307och rekommenderas att användas istället för 302. Du behöver bara ändra metoden om servern svarade 303. I andra fall görs nästa begäran med den ursprungliga metoden.
Beteendet hos klienter för olika omdirigeringar beskrivs i tabellen:
- 300 Multiple Choices - På den angivna URI:n finns det flera alternativ för att tillhandahålla en resurs efter MIME -typ , efter språk eller efter andra egenskaper. Servern skickar en lista med alternativ med meddelandet, vilket gör att valet kan göras automatiskt av klienten eller användaren. Introducerad i HTTP/1.0.
- 301 Flyttat permanent - Det begärda dokumentet har flyttats permanent till den nya URI som anges i Locationrubrikfältet. Vissa klienter beter sig felaktigt när de bearbetar den här koden. Introducerad i HTTP/1.0.
- 302 Hittade, 302 flyttade tillfälligt - Det begärda dokumentet är tillfälligt tillgängligt på en annan URI som anges i rubriken i Location. Den här koden kan till exempel användas i serverdriven innehållsförhandling . Några[ vad? ] klienter beter sig felaktigt när de bearbetar den här koden. Introducerad i HTTP/1.0.
- 303 Se Annat - Dokumentet på den begärda URI:n måste begäras på adressen i Locationrubrikfältet med metoden GET, även om det första begärdes med en annan metod. Denna kod introducerades tillsammans med koden 307för att undvika oklarheter så att servern kan vara säker på att nästa resurs kommer att begäras av GET. Till exempel har en webbsida ett textinmatningsfält för snabb navigering och sökning. Efter att ha angett data gör webbläsaren en begäran med metoden POST, inklusive den inmatade texten i meddelandets brödtext. Om ett dokument med det angivna namnet hittas svarar servern med koden 303och anger Locationdess permanenta adress i rubriken. Då kommer webbläsaren garanterat att begära det med en metod GETför att få innehållet. Annars kommer servern helt enkelt att returnera sökresultatsidan till klienten. Introducerad i HTTP/1.1.
- 304 Ej modifierad - Servern returnerar denna kod om klienten begärde dokumentet med hjälp av GETrubriken If-Modified-Sinceeller , If-None-Matchoch dokumentet inte har ändrats sedan den angivna tiden. I det här fallet får servermeddelandet inte innehålla en text. Introducerad i HTTP/1.0.
- 305 Använd proxy - Begäran om den begärda resursen måste göras via en proxyserver vars URI anges i Locationrubrikfältet. Denna svarskod kan endast användas av ursprungs-HTTP-servrar (inte proxyservrar). Introducerad i HTTP/1.1.
- 306 (Reserverad) - Används i tidigare versioner av specifikationen, svarskoden är för närvarande reserverad. Nämnd i RFC 2616 (HTTP/1.1-uppdatering). Enligt tidiga utkast betydde koden Switch Proxy, som säger åt klienten att ändra proxyn som används till den som specificeras av servern i svarshuvudet [18] .
- 307 Temporary Redirect - Den begärda resursen är kort tillgänglig på en annan URI som anges i Locationrubrikfältet. Förfrågningsmetoden (GET/POST) får inte ändras. Till exempel måste en POST-begäran skickas till en ny URI med samma POST-metod. Denna kod introducerades tillsammans med 303 istället för 302 för att undvika oklarheter. Introducerad i RFC 2616 (HTTP/1.1-uppdatering).
- 308 Permanent omdirigering - Den begärda resursen har flyttats permanent till den nya URI som anges i Locationrubrikfältet. Förfrågningsmetoden (GET/POST) får inte ändras. Till exempel måste en POST-begäran skickas till en ny URI med samma POST-metod. Denna kod introducerades istället för 301 för att undvika oklarheter. Introducerad i RFC 7238 ( RFC 7538 ).
Klientfel
Klassen av koder 4xxär avsedd att indikera fel på klientsidan. När du använder alla metoder utom HEAD, måste servern returnera en hypertextförklaring för användaren i meddelandets brödtext.
- 400 Bad Request - Servern stötte på ett syntaxfel i klientens begäran. Introducerad i HTTP/1.0.
- 401 obehörig - autentisering krävs för att komma åt den begärda resursen . Svarshuvudet måste innehålla ett fält WWW-Authenticatemed en lista över autentiseringsvillkor. Med andra ord, för att komma åt den begärda resursen måste klienten presentera sig själv genom att skicka en begäran, samtidigt som ett fält Authorizationmed de data som krävs för autentisering inkluderas i meddelandehuvudet. Om begäran redan innehåller auktoriseringsdata betyder ett 401-svar att auktorisering med den nekas.
- 402 Betalning krävs - avsedd att användas i framtiden[ när? ] . För närvarande[ när? ] används inte. Den här koden är för betalda användartjänster, inte för webbhotell . Det betyder att detta fel inte kommer att utfärdas av värdleverantören i händelse av försenad betalning för dess tjänster. Reserverat sedan HTTP/1.1.
- 403 Förbjudet [19] - Servern förstod begäran, men den vägrar att uppfylla den på grund av begränsningar i åtkomst för klienten till den angivna resursen. Med andra ord är klienten inte behörig att utföra operationer på den begärda resursen. Om åtkomst till en resurs kräver HTTP-autentisering kommer servern att returnera ett svar 401, eller 407när en proxy används. Annars har gränserna satts av serveradministratören eller utvecklaren av webbapplikationen och kan variera beroende på kapaciteten hos programvaran som används . I vilket fall som helst BÖR servern informeras om skälen för att vägra att behandla begäran. De mest troliga orsakerna till begränsningen kan vara ett försök att få åtkomst till systemresurserna på webbservern (till exempel filer .htaccesseller .htpasswd) eller filer som nekades med hjälp av konfigurationsfiler, kravet på annan autentisering än HTTP, till exempel för att få tillgång till innehållshanteringssystemet eller avsnittet för registrerade användare, eller så är servern inte nöjd med klientens IP-adress , till exempel när den är blockerad. Introducerad i HTTP/1.0.
- 404 Not Found [20] är det vanligaste felet när man använder Internet, den främsta orsaken är ett misstag när man skriver adressen till en webbsida. Servern förstod begäran, men hittade inte en matchande resurs på den angivna webbadressen. Om servern vet att det fanns ett dokument på den här adressen är det önskvärt att använda koden 410 . Svaret 404kan användas istället 403för om du noggrant vill dölja vissa resurser från nyfikna ögon. Introducerad i HTTP/1.0.
- 405 Metod ej tillåten - Metoden som specificeras av klienten kan inte tillämpas på den aktuella resursen. I svaret måste servern ange de tillgängliga metoderna i rubriken Allow, separerade med ett kommatecken. Servern bör returnera detta fel om metoden är känd för den, men den är inte tillämplig specifikt på resursen som anges i begäran, men om den angivna metoden inte är tillämplig på hela servern, måste klienten returnera koden 501( Ej implementerad). Introducerad i HTTP/1.1.
- 406 Not Acceptable - Den begärda URI:n kan inte uppfylla egenskaperna som skickas i rubriken. Om metoden inte var HEAD, bör servern returnera en lista med giltiga egenskaper för den givna resursen. Introducerad i HTTP/1.1.
- 407 Proxyautentisering krävs - Svaret liknar koden 401, förutom att autentisering utförs för en proxyserver. Mekanismen liknar autentisering på ursprungsservern. Introducerad i HTTP/1.1.
- 408 Request Timeout - Servern tog timeout i väntan på en överföring från klienten. Klienten kan när som helst upprepa begäran liknande den föregående. Till exempel kan en sådan situation uppstå när en stor fil laddas upp till servern med hjälp av POSTeller PUT. Vid något tillfälle under överföringen slutade datakällan att svara, till exempel på grund av en skadad CD eller förlust av kommunikation med en annan dator i det lokala nätverket. Så länge klienten inte sänder något, väntar på ett svar från den, upprätthålls anslutningen till servern. Efter en tid kan servern stänga anslutningen på sin sida för att tillåta andra klienter att göra en begäran. Detta svar returneras inte när klienten tvångsstoppat överföringen på användarens kommando eller anslutningen avbröts av någon annan anledning, eftersom svaret inte längre kan skickas. Introducerad i HTTP/1.1.
- 409 Konflikt - Begäran kunde inte slutföras på grund av en resurskonflikt. Detta kan till exempel hända när två klienter försöker modifiera en resurs med hjälp av PUT. Introducerad i HTTP/1.1.
- 410 Borta - servern skickar ett sådant svar om resursen brukade vara på den angivna URL:en, men raderades och är nu otillgänglig. I det här fallet känner inte servern heller till var det alternativa dokumentet finns (till exempel en kopia). Introducerad i HTTP/1.1.
- 411 Längd krävs - För den angivna resursen måste klienten specificera Content-Lengthi förfrågningshuvudet. Utan att ange det här fältet bör du inte göra om begäran till servern för denna URI. Ett sådant svar är naturligt för frågor som POSToch PUT. Till exempel, om filer laddas ner på angiven URI och det finns en gräns för deras volym på servern. Då skulle det vara klokare att kontrollera rubriken i början Content-Lengthoch omedelbart vägra ladda ner, än att provocera fram en meningslös belastning genom att bryta anslutningen när klienten verkligen skickar ett meddelande som är för stort. Introducerad i HTTP/1.1.
- 412 Precondition Failed - Returneras om inget av de villkorliga rubrikfälten (If-Match, etc., se RFC 7232 ) i begäran har fyllts i. Introducerad i HTTP/1.1.
- 413 Payload Too Large - Returneras om servern vägrar att behandla begäran på grund av att begäran är för stor. Servern KAN stänga anslutningen för att stoppa ytterligare överföring av begäran. Om problemet är tillfälligt rekommenderas det att inkludera en rubrik i serversvaret som Retry-Afteranger efter vilken tid en liknande begäran kan upprepas. Introducerad i HTTP/1.1. Tidigare kallad "Request Entity Too Large".
- 414 URI för lång - Servern kan inte behandla begäran eftersom den angivna URI är för lång. Ett sådant fel kan till exempel framkallas när klienten försöker skicka långa parametrar genom metoden GETistället för POST. Introducerad i HTTP/1.1. Tidigare kallad "Request-URI Too Long".
- 415 Mediatyp som inte stöds - av någon anledning vägrar servern att arbeta med den angivna datatypen med denna metod. Introducerad i HTTP/1.1.
- 416 Range Not Satisfiable - Ett Rangeintervall utanför resursen specificerades i fältet för begäransrubrik och fältet saknas If-Range. Om klienten skickade ett byteintervall, KAN servern returnera den faktiska storleken i Content-Rangerubrikfältet. Detta svar ska inte användas vid godkänd typmultipart/byteranges . Introducerad i RFC 2616 (HTTP/1.1-uppdatering). Tidigare kallad "Requested Range Not Satisfiable".
- 417 Förväntningen misslyckades - Av någon anledning kan servern inte tillfredsställa värdet för Expectförfrågningshuvudfältet. Introducerad i RFC 2616 (HTTP/1.1-uppdatering).
- 418 I'm a teapot - Denna kod introducerades 1998 som ett av de traditionella IETF aprilskämten i RFC 2324 , Hyper Text Coffee Pot Control Protocol . Denna kod förväntas inte stödjas av riktiga servrar [21] .
- 419 Authentication Timeout (inte i RFC 2616 ) - Den här koden finns inte i RFC 2616 , används som ett alternativ till 401-koder som är autentiserade men som nekas åtkomst till vissa serverresurser. Vanligtvis ges koden om CSRF-token är föråldrad eller visar sig vara felaktig.
- 421 Missdirected Request - Begäran omdirigerades till en server som inte kunde svara.
- 422 Unprocessable Entity - servern har framgångsrikt accepterat begäran, kan arbeta med den angivna typen av data (till exempel innehåller förfrågningskroppen ett XML- dokument som har rätt syntax), men det finns något slags logiskt fel på grund av vilket det är omöjligt att utföra en operation på resursen. Introducerad i WebDAV .
- 423 Låst - Målresursen från begäran blockeras från att tillämpa den angivna metoden på den. Introducerad i WebDAV .
- 424 Misslyckat beroende - Implementeringen av den aktuella begäran kan bero på framgången för en annan operation. Om den inte exekveras och på grund av detta är det omöjligt att utföra den aktuella begäran, kommer servern att returnera denna kod. Introducerad i WebDAV .
- 425 för tidigt - Servern är inte redo att acceptera riskerna med att behandla "tidig information". Introducerad i RFC 8470 för att skydda mot reprisattacker vid användning av 0-RTT i TLS 1.3.
- 426 Uppgradering krävs - Servern instruerar klienten att uppgradera protokollet. Svarshuvudet måste innehålla välformade Upgradeoch fält Connection. Introducerad i RFC 2817 för att möjliggöra övergång till TLS över HTTP.
- 428 Förutsättning krävs - Servern säger åt klienten att använda villkorsrubriker som If-Match. Infört i utkastet till RFC 6585 .
- 429 Too Many Requests - Klienten försökte skicka för många förfrågningar på kort tid, vilket kan tyda på till exempel ett försök till DDoS-attack. Kan åtföljas av en Retry-After-rubrik som anger hur länge begäran kan prövas på nytt. Infört i utkastet till RFC 6585 .
- 431 Request Header Fields Too Large - Den tillåtna längden på rubriker har överskridits. Servern behöver inte svara med den här koden, istället kan den helt enkelt återställa anslutningen. Infört i utkastet till RFC 6585 .
- 434 Begärd värd inte tillgänglig - Den begärda adressen är inte tillgänglig .
- 449 Försök igen med - Returneras av servern om inte tillräckligt med information mottagits från klienten för att bearbeta begäran. I det här fallet placeras fältet i svarshuvudet Ms-Echo-Request. Introducerad av Microsoft för WebDAV . För närvarande[ när? ] används av åtminstone Microsoft Money .
- 451 Ej tillgänglig av juridiska skäl - tillgången till resursen stängs av juridiska skäl, till exempel på begäran av offentliga myndigheter eller på begäran av upphovsrättsinnehavaren vid upphovsrättsintrång. Introducerad i ett IETF-utkast av Google [12] , med felkoden som en referens till Ray Bradburys roman Fahrenheit 451 . Den lades till standarden den 21 december 2015 [22] .
- 499 Client Closed Request är en icke-standardkod som föreslås och används av nginx för fall där klienten stängde anslutningen medan nginx bearbetade begäran.
Serverfel
Koderna 5xxär dedikerade till fall av obehandlade undantag när man utför operationer på serversidan. För alla andra situationer än att använda metoden HEADMÅSTE servern inkludera en förklaring i meddelandets brödtext som klienten kommer att visa för användaren.
- 500 Internt serverfel [23] Alla internt serverfel som inte täcks av resten av klassfelen. Introducerad i HTTP/1.0.
- 501 Ej implementerad - Servern stöder inte de funktioner som krävs för att behandla begäran. Ett typiskt svar för fall där servern inte förstår den metod som anges i begäran. Om metoden är känd för servern, men den inte är tillämplig på den här resursen, måste du returnera svaret 405. Introducerad i HTTP/1.0.
- 502 Bad Gateway - Servern, som fungerar som en gateway eller proxyserver, fick ett ogiltigt svarsmeddelande från en uppströmsserver. Introducerad i HTTP/1.0.
- 503 Tjänst ej tillgänglig - servern kan tillfälligt inte behandla förfrågningar av tekniska skäl (underhåll, överbelastning, etc.). I Retry-Afterrubrikfältet kan servern ange den tid efter vilken det rekommenderas att klienten upprepar begäran. Även om det verkar självklart att omedelbart avsluta anslutningen under överbelastning, kan det vara mer effektivt att ställa in fältet till ett högt värde Retry-Afterför att minska frekvensen av redundanta förfrågningar. Introducerad i HTTP/1.0.
- 504 Gateway Timeout - Servern som fungerade som en gateway eller proxy väntade inte på ett svar från uppströmsservern för att slutföra den aktuella begäran. Introducerad i HTTP/1.1.
- 505 HTTP-version stöds inte - Servern stöder inte eller vägrar att stödja versionen av HTTP-protokollet som anges i begäran. Introducerad i HTTP/1.1.
- 506 Variant förhandlar också - Som ett resultat av en felaktig konfiguration pekar den valda varianten på sig själv, på grund av vilken länkningsprocessen avbryts. Experimentell. Introducerad i RFC 2295 för att utöka HTTP-protokollet med Transparent Content Negotiation -teknologi .
- 507 Otillräckligt lagringsutrymme - Det finns inte tillräckligt med utrymme för att slutföra den aktuella begäran. Problemet kan vara tillfälligt. Introducerad i WebDAV .
- 508 loop upptäckt - Operation avbröts pga servern stötte på en oändlig loop under bearbetning av en begäran utan djupgräns. Introducerad i WebDAV .
- 508 Resource Limit Reached är en variant av fel 508 i CloudLinux som uppstår när värdgränserna nås [24] .
- 509 Bandwidth Limit Exceeded - används när webbplatsen överskrider gränsen för trafikförbrukning som tilldelats den. I det här fallet bör webbplatsägaren kontakta sin värdleverantör. För närvarande beskrivs den här koden inte i någon RFC och används endast av modulen "bw/limited" som ingår i cPanel -värdkontrollpanelen , där den introducerades.
- 510 Not Extended - Servern har inte ett tillägg som klienten vill använda. Servern kan eventuellt skicka information om tillägg som är tillgängliga för den. Introducerad i RFC 2774 för att utöka HTTP-protokollet med stöd för tillägg.
- 511 Nätverksautentisering krävs - detta svar skickas inte av servern som begäran var avsedd till, utan av en mellanliggande server - till exempel leverantörens server - om klienten först måste logga in på nätverket, t.ex. ange ett lösenord för en betald Internetåtkomstpunkt. Det antas att svaret kommer att returnera ett webbauktoriseringsformulär eller en omdirigering till det. Infört i utkastet till RFC 6585 .
- 520 Okänt fel, inträffar när CDN -servern inte kunde bearbeta webbserverfelet; anpassad CloudFlare- kod .
- 521 Web Server Is Down, inträffar när CDN- anslutningar avvisas av webbservern; anpassad CloudFlare- kod .
- 522 Connection Timed Out, inträffar när CDN misslyckades med att ansluta till webbservern; anpassad CloudFlare- kod .
- 523 Origin Is Unreachable, inträffar när webbservern inte kan nås; anpassad CloudFlare- kod .
- 524 En timeout inträffade, inträffar när anslutningen timeout mellan CDN -servern och webbservern. anpassad CloudFlare- kod .
- 525 SSL-handskakning misslyckades, inträffar när SSL - handskakning mellan CDN -servern och webbservern misslyckas; anpassad CloudFlare- kod .
- 526 Ogiltigt SSL-certifikat, inträffar när webbserverns krypteringscertifikat inte kan valideras; anpassad CloudFlare- kod .
Se även
Anteckningar
- ↑ 1 2 2.2.6 449 "Försök igen med statuskod" // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. Arkiverad 5 oktober 2009 på Wayback Machine på MSDN
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 35 34 och 36 31 32 33 36 . 7, 2018 på Wayback Machine » i RFC 2068
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 613 RFC 2 . Datum för åtkomst: 29 juli 2009. Arkiverad från originalet den 7 mars 2011. (obestämd)
- ↑ 1 2 3 IETF-utkast till WebDAV Advanced Collections Protocol - S.4.2.5 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012. (obestämd)
- ↑ IETF utkast till WebDAV Advanced Collections Protocol - S.10 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012. (obestämd)
- ↑ rfc5842 . Hämtad 12 september 2017. Arkiverad från originalet 10 oktober 2017. (obestämd)
- ↑ 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Omdirigering 3xx" (sid. 61) . Datum för åtkomst: 29 juli 2009. Arkiverad från originalet den 7 mars 2011. (obestämd)
- ↑ rfc7538 . Hämtad 12 september 2017. Arkiverad från originalet 16 april 2015. (obestämd)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.4.3.1.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012. (obestämd)
- ↑ rfc7540 . Hämtad 12 september 2017. Arkiverad från originalet 23 juni 2015. (obestämd)
- ↑ 1 2 3 4 RFC 6585
- ↑ 1 2 IETF utarbetar en ny HTTP-statuskod för att rapportera juridiska hinder . Hämtad 6 mars 2013. Arkiverad från originalet 22 maj 2013. (obestämd)
- ↑ RFC 2295 Transparent Content Negotiation i HTTP - S.8.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 8 juni 2012. (obestämd)
- ↑ IETF Draft WebDAV Advanced Collections Protocol - S.7.1 . Datum för åtkomst: 18 maj 2012. Arkiverad från originalet den 9 juli 2012. (obestämd)
- ↑ 1 2 3 4 5 6 7 Felsidor - CloudFlare Support . Hämtad 18 april 2016. Arkiverad från originalet 4 mars 2016. (obestämd)
- ↑ RFC 2068 "10.3 Redirection 3xx" (sid. 56) Arkiverad 7 juni 2018 på Wayback Machine .
- ↑ RFC 2616 , avsnitt "10.3.3 302 Found", sida 63 Arkiverad 7 mars 2011 på Wayback Machine .
- ↑ Josh Cohen HTTP/1.1 305 och 306 svarskoder Arkiverade 8 september 2014 på Wayback Machine // Netscape Communications Corp., 25 december 1996
- ↑ Vad betyder 403 Förbjudet? Arkiverad 21 februari 2014 på Wayback Machine .
- ↑ Orsaker till ett 404 Not Found Error Arkiverad 21 februari 2014 på Wayback Machine .
- ↑ RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) .
- ↑ draft-ietf-httpbis-legaly-restricted-status-04 . datatracker.ietf.org. Hämtad 22 december 2015. Arkiverad från originalet 23 december 2015. (obestämd)
- ↑ Beskrivning av 500 internt serverfel Arkiverat 21 februari 2014 på Wayback Machine .
- ↑ Resursgränsen nådd . www.cloudlinux.com _ Hämtad 21 juni 2022. Arkiverad från originalet 15 maj 2021. (obestämd)
Länkar
HTTP-kärndokument (fallande efter publiceringsdatum)
- Hypertext Transfer Protocol ( HTTP ) statuskodregister . IANA (17 oktober 2007). - Register för HTTP-statuskod. Datum för åtkomst: 30 juli 2009. Arkiverad från originalet den 17 februari 2012.
- RFC 2616 Utkast till standard " Hypertext Transfer Protocol - HTTP/1.1 " ( engelska ) IETF , juni 1999; Fielding Roy ( UC Irvine), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT ) - uppdatering av HTTP-protokollet version 1.1.
- RFC 2068 Föreslagen standard " Hypertext Transfer Protocol - HTTP/1.1 " (engelska) (från engelska - "Hypertext Transfer Protocol - HTTP/1.1"); IETF , januari 1997; Fielding Roy ( UC Irvine), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS) är en tidig specifikation för HTTP-version 1.1.
- RFC 1945 informativ " Hypertext Transfer Protocol - HTTP / 1.0 " IETF , maj 1996; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine), Frystyk Henrik( MIT /LCS) är den allra första specifikationen för HTTP-protokollet. Innehåller även en beskrivning av HTTP/0.9.
Dokument om HTTP-protokolltillägg och uppdateringar (fallande efter publiceringsdatum)
- RFC 4918 Proposed Standard " HTTP Extensions for Web Distributed Authoring and Versioning ( WebDAV ) " IETF , juni 2007; Dusseault Ed. L. ( CommerceNet) är en sen specifikation för WebDAV-protokollet, som ersätter RFC 2518 .
- RFC 3229 Föreslagen standard " Delta-kodning i HTTP " (engelska) (från engelska - "Delta-kodning i HTTP"); IETF , januari 2002; Mogul J. ( Compaq WRL), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
- RFC 2817 föreslagna standard " Uppgradering till TLS inom HTTP / 1.1 " IETF , maj 2000; Khare Rohit(4K Associates/ UC Irvine), Lawrence S. (Agranat Systems, Inc.) - uppdatering till RFC 2616 för att beskriva hur HTTP och TLS fungerar .
- RFC 2774 Experimental " An HTTP Extension Framework " (engelska) (från engelska - "HTTP Extension Framework"); IETF , februari 2000; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
- Internet Draft " WebDAV Advanced Collections Protocol " (från engelska - "WebDAV Advanced Collections Protocol "); IETF , 18 juni 1999; Slein J. ( Xerox ), Whitehead Jr. EJ ( UC Irvine), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel) - samlingshantering i WebDAV; gick ut den 18 december 1999.
- RFC 2518 Proposed Standard " HTTP Extensions for Distributed Authoring - WEBDAV " IETF , februari 1999; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell ) - den första specifikationen för WebDAV-protokollet (ersatt av RFC 4918 ).
- RFC 2295 Experimentell Transparent Content Negotiation i HTTP IETF , mars 1998; Holtman K. (TUE), Mutz A. ( Hewlett-Packard ) .
Ytterligare material
Webb och hemsidor |
---|
globalt |
|
---|
Lokalt |
|
---|
Typer av webbplatser och tjänster |
|
---|
Skapande och underhåll |
|
---|
Typer av layouter, sidor, webbplatser |
|
---|
Teknisk |
|
---|
Marknadsföring |
|
---|
Samhälle och kultur |
|
---|