Verktyg online
Http statuskoder Statuskod Betydelse
100 Klienten bör fortsätta att skicka förfrågningar. Detta tillfälliga svar används för att informera klienten om att en del av begäran har tagits emot av servern och inte har avvisats. Klienten bör fortsätta att skicka resten av begäran, eller ignorera detta svar om begäran är komplett. Servern skall skicka ett slutligt svar till klienten när begäran är komplett.
101 Servern har förstått klientens begäran och kommer att meddela klienten via Upgrade-headern att ett annat protokoll användes för att slutföra begäran. Efter att ha skickat den sista tomma raden i svaret kommer servern att byta till de protokoll som definieras i Upgrade-headern. Detta bör endast göras om det är mer fördelaktigt att byta till det nya protokollet. Det kan t.ex. vara mer fördelaktigt att byta till en ny version av HTTP än en äldre version, eller att byta till ett synkroniserat realtidsprotokoll för att leverera resurser som utnyttjar sådana funktioner.
102 Statuskoder, utökade av WebDAV (RFC 2518), indikerar att bearbetningen kommer att fortsätta.
200 Begäran var framgångsrik och de svarshuvuden eller den datakropp som begärdes av begäran kommer att returneras med svaret.
201 Begäran har uppfyllts och en ny resurs har skapats som svar på begäran, och dess URI har returnerats med Location-headern. Om den begärda resursen inte kan skapas i tid bör följande returneras'202 Accepted'。
202 Servern har accepterat begäran, men har ännu inte behandlat den. Precis som den kan avvisas, kan det hända att begäran inte utförs i slutändan. När det gäller asynkrona operationer finns det inget bekvämare än att skicka denna statuskod. Syftet med att returnera ett 202-svar är att göra det möjligt för servern att acceptera begäranden från andra processer (t.ex. en batchbaserad operation som bara körs en gång om dagen) utan att klienten behöver upprätthålla en anslutning till servern förrän batchoperationen är klar. Ett svar som accepterar en begäran om bearbetning och returnerar en 202-statuskod bör i den returnerade enheten innehålla viss information som anger processens aktuella status, samt en pekare till en bearbetningsstatusövervakare eller statusförutsägelse, så att användaren kan uppskatta om åtgärden har slutförts eller inte.
203 Servern har framgångsrikt behandlat begäran, men den returnerade metainformationen i entitetshuvudet är inte en slutgiltig uppsättning som är giltig på den ursprungliga servern, utan en kopia från en lokal eller tredje part. Den aktuella informationen kan vara en delmängd eller en övermängd av originalet. Metadata som innehåller resurser kan t.ex. leda till att ursprungsservern känner till meta-information super. Det är inte obligatoriskt att använda denna statuskod och den är endast lämplig om svaret skulle ha returnerat 200 OK utan den.
204 Servern behandlade begäran framgångsrikt, men behöver inte returnera något fysiskt innehåll utan vill returnera uppdaterad metainformation. Svaret kan returnera ny eller uppdaterad metainformation i form av entitetsrubriker. Om dessa headers finns bör de motsvara de begärda variablerna. Om klienten är en webbläsare bör användarens webbläsare behålla den sida på vilken begäran skickades utan att dokumentvyn ändras, även om den nya eller uppdaterade metainformationen enligt specifikationen bör tillämpas på dokumentet i den aktiva vyn i användarens webbläsare. Eftersom 204-svaret inte får innehålla någon meddelandekropp avslutas det alltid med den första tomma raden efter meddelandehuvudet.
205 Servern hanterar begäran framgångsrikt och returnerar ingenting. Till skillnad från 204-svaret ber dock det svar som returnerar denna statuskod den som begär det att återställa dokumentvyn. Detta svar används främst för att återställa formuläret omedelbart efter att det har accepterat användarens inmatning så att användaren enkelt kan påbörja en ny inmatning. Liksom 204-svaret får detta svar inte innehålla någon meddelandetext och slutar med den första tomma raden efter meddelandehuvudet.
206 Servern har framgångsrikt behandlat en del av GET-begäran. HTTP-nedladdningsverktyg som FlashGet eller Thunderbolt använder den här typen av svar för att utföra intermittenta nedladdningar eller för att dela upp en stor fil i flera nedladdningar samtidigt. Begäran måste innehålla en Range-header för att ange det innehållsintervall som klienten vill ta emot och kan innehålla en If-Range som ett villkor för begäran. Svaret måste innehålla följande rubrikfält: Content-Range för att ange omfattningen av det innehåll som returneras i detta svar, eller, när det gäller nedladdningar i flera delar med en Content-Type av typen multipart/byteranges, ett Content-Range-fält i varje segment av flera delar för att ange omfattningen av innehållet i det segmentet. Om svaret innehåller en Content-Length måste dess värde motsvara det verkliga antalet bytes i det innehållsområde som returneras. Expires, Cache-Control och/eller Vary, om deras värden kan skilja sig från värdena i andra tidigare svar med samma variabler. Detta svar bör inte innehålla andra entitetsrubriker om begäran använder stark If-Range-cacheverifiering, och bör inte innehålla andra entitetsrubriker om begäran använder svag If-Range-cacheverifiering; detta undviker inkonsekvenser mellan det cachade entitetsinnehållet och den uppdaterade entitetsrubriksinformationen. I annat fall BÖR detta svar innehålla alla de entitetshuvudfält som skulle ha returnerats i 200-svaret. Om ETag- eller Last-Modified-rubrikerna inte matchar varandra exakt bör cachen på klientsidan inte tillåta att innehållet som returneras i svar 206 kombineras med något tidigare cachelagrat innehåll. En cache som inte stöder Range- och Content-Range-rubrikerna får inte cachelagra det innehåll som returneras i 206-svaret.
207 Statuskoder utökade av WebDAV(RFC 2518) Statuskoden, som utökats av WebDAV, innebär att den efterföljande meddelandetexten kommer att vara ett XML-meddelande och kan innehålla en serie separata svarskoder, beroende på antalet tidigare underförfrågningar.
300 Den begärda resursen har en rad alternativa svar, vart och ett med sin egen specifika adress och webbläsarstyrda förhandlingsinformation. Det är upp till användaren eller webbläsaren att välja en önskad adress för omdirigering. Om det inte rör sig om en HEAD-begäran bör svaret innehålla en entitet som är en lista över resursegenskaper och adresser från vilken användaren eller webbläsaren kan välja den lämpligaste omdirigeringsadressen. Formatet på denna entitet bestäms av formatet på definitionen av Content-Type. Webbläsaren kan automatiskt göra det lämpligaste urvalet baserat på svarets format och webbläsarens egna möjligheter. RFC 2616-specifikationen anger naturligtvis inte hur detta automatiska val ska göras. Om servern själv redan har ett föredraget returalternativ bör returens URI anges i Location; webbläsare kan använda detta Location-värde som adress för automatisk omdirigering. Dessutom är svaret cachebart om inget annat anges.
301 Den begärda resursen har flyttats permanent till den nya platsen och alla framtida hänvisningar till den bör använda en av de flera URI:er som returneras i detta svar. Om möjligt bör klienter med länkredigeringsfunktioner automatiskt ändra den begärda adressen till den som returneras från servern. Detta svar kan också cachas om inte annat anges. Den nya permanenta URI:n bör returneras i fältet Location i svaret. Om detta inte är en HEAD-begäran bör svarsentiteten innehålla en hyperlänk till den nya URI:n och en kort beskrivning. Om detta inte är en GET- eller HEAD-begäran får webbläsaren inte automatiskt omdirigera om inte användaren bekräftar detta, eftersom villkoren för begäran kan ändras till följd av detta. Obs: För vissa webbläsare som använder HTTP/1.0-protokollet, när de skickar en POST-begäran och får ett 301-svar, kommer nästa omdirigeringsbegäran att vara GET.
302 Den begärda resursen svarar nu tillfälligt på begäran från en annan URI. Eftersom denna omdirigering är tillfällig bör klienten fortsätta att skicka framtida förfrågningar till den ursprungliga adressen. Svaret kan endast cachas om det anges i Cache-Control eller Expires. Den nya tillfälliga URI:n bör returneras i fältet Location i svaret. Om det inte är en HEAD-begäran ska svarsentiteten innehålla en hyperlänk till den nya URI:n och en kort beskrivning. Om detta inte är en GET- eller HEAD-begäran får webbläsaren inte automatiskt omdirigera om inte användaren bekräftar detta, eftersom villkoren för begäran kan ändras som ett resultat av detta. Observera: Även om specifikationerna RFC 1945 och RFC 2068 inte tillåter att klienten ändrar metoden för begäran under omdirigeringen, behandlar många befintliga webbläsare 302-svaret som ett 303-svar och använder GET för att komma åt den URI som anges i Location, utan att ta hänsyn till metoden för den ursprungliga begäran. Statuskoderna 303 och 307 har lagts till för att klargöra vilket svar servern förväntar sig från klienten.
303 Svaret på den aktuella begäran finns på en annan URI, och klienten bör komma åt den resursen med GET. Den här metoden finns främst för att skriptaktiverade POST-begäranden ska kunna omdirigeras till en ny resurs. Denna nya URI är inte en ersättningsreferens till den ursprungliga resursen. Dessutom får 303-svaret inte cachelagras. Naturligtvis kan den andra begäran (omdirigering) cachelagras. Den nya URI:n ska returneras i fältet Location i svaret. Om det inte rör sig om en HEAD-begäran bör svarsentiteten innehålla en hyperlänk till den nya URI:n och en kort beskrivning. Observera: Många webbläsare före HTTP/1.1 förstår inte 303-läget korrekt. Om interaktion med dessa webbläsare måste övervägas, bör statuskoden 302 fungera, eftersom de flesta webbläsare hanterar 302-svaret på exakt samma sätt som specifikationen ovan kräver att klienten hanterar 303-svaret.
304 Denna statuskod bör returneras av servern om klienten skickar en villkorlig GET-begäran och begäran är tillåten, och innehållet i dokumentet inte har ändrats (varken sedan det senaste besöket eller enligt villkoren för begäran). 304-svar är förbjudna att innehålla en meddelandekropp och slutar därför alltid med den första tomma raden efter meddelandets rubrik. Svaret måste innehålla följande rubrikinformation: Datum, såvida inte servern saknar klocka. Om servern inte har någon klocka följer dessa regler kan proxyservern och klienten själva lägga till fältet Date i det inkommande svarshuvudet (enligt RFC 2068), och cachemekanismen kommer att fungera korrekt.ETag och/eller Content-Location, om samma begäran skulle ha returnerat ett 200-svar. Expires, Cache-Control och/eller Vary, om deras värden kan skilja sig från värdena i andra tidigare svar med samma variabler. Om svarsförfrågan använder stark cache-validering ska svaret inte innehålla ytterligare entitetsrubriker; i annat fall (t.ex. om en villkorlig GET-förfrågan använder svag cache-validering) är det förbjudet för svaret att innehålla ytterligare entitetsrubriker; detta undviker inkonsekvenser mellan cachat entitetsinnehåll och uppdaterad entitetsrubriksinformation. Om ett 304-svar anger att en entitet för närvarande inte finns i cachen måste cachesystemet ignorera svaret och upprepa begäran utan begränsningen. Om ett 304-svar mottas med begäran om att en cache-post ska uppdateras, MÅSTE cachesystemet uppdatera hela posten så att den återspeglar värdena för alla fält som uppdaterats i svaret.
305 Den begärda resursen måste nås via en angiven proxy. Fältet Location ger information om URI:n för den angivna proxyn och mottagaren måste skicka en separat begäran flera gånger för att nå resursen via denna proxy. Endast den ursprungliga servern kan skapa ett 305-svar. Observera: Det framgår inte tydligt av RFC 2068 att ett 305-svar är avsett att omdirigera en enda begäran och endast kan skapas av ursprungsservern. Om dessa begränsningar ignoreras kan det leda till allvarliga säkerhetskonsekvenser.
306 I den senaste versionen av specifikationen används inte längre statuskoden 306.
307 Begärda resurser svarar nu tillfälligt på förfrågningar från olika URI:er. Eftersom denna omdirigering är tillfällig bör klienter fortsätta att skicka framtida förfrågningar till den ursprungliga adressen. Detta svar kan endast cachas om det anges i Cache-Control eller Expires. Den nya tillfälliga URI:n bör returneras i fältet Location i svaret. Om det inte är en HEAD-begäran ska svarsenheten innehålla en hyperlänk till den nya URI:n och en kort beskrivning. Eftersom vissa webbläsare inte känner igen 307-svaret är det nödvändigt att lägga till ovanstående information så att användaren kan förstå och begära åtkomst till den nya URI:n. Om detta inte är en GET- eller HEAD-begäran förbjuder webbläsaren automatisk omdirigering, såvida inte användaren bekräftar det, eftersom villkoren för begäran kan ändras.
400 1, semantiskt fel, den aktuella begäran kan inte förstås av servern. Om den inte ändras bör klienten inte upprepa begäran. 2, parametrarna för begäran är felaktiga.
401 Den aktuella begäran kräver användarautentisering. Svaret måste innehålla en WWW-Authenticate header för den begärda resursen för att be om användarinformation. Klienten kan skicka en begäran på nytt med lämplig information i Authorisation-headern. Om den aktuella begäran redan innehåller autentiseringsuppgifter innebär ett 401-svar att servern kontrollerar att dessa uppgifter har avvisats. Om 401-svaret innehåller samma autentiseringsfråga som det föregående svaret och webbläsaren redan har gjort minst ett autentiseringsförsök, bör webbläsaren visa användaren den entitetsinformation som finns i svaret, eftersom denna entitetsinformation kan innehålla relevant diagnostisk information. Se RFC 2617.
402 Denna statuskod är reserverad för eventuella framtida krav.
403 Servern har förstått begäran, men vägrar att utföra den. Till skillnad från ett 401-svar ger autentiseringen ingen hjälp och begäran bör inte skickas på nytt. Om detta inte är en HEAD-begäran och servern vill kunna ange varför begäran inte kan utföras, bör orsaken till vägran beskrivas i entiteten. Naturligtvis kan servern också returnera ett 404-svar om den inte vill att klienten ska få någon information.
404 Begäran misslyckades, den begärda resursen hittades inte på servern. Det finns ingen information som talar om för användaren om situationen är tillfällig eller permanent. Om servern är medveten om situationen bör den använda statuskoden 410 för att informera servern om att den gamla resursen är permanent otillgänglig på grund av någon intern konfigurationsmekanism och att det inte finns någon omdirigering tillgänglig. 404 används ofta när servern inte vill avslöja varför begäran avvisades eller när det inte finns något annat lämpligt svar tillgängligt.
405 Den begärandemetod som anges i begäranderaden kan inte användas för att begära motsvarande resurs. Svaret måste returnera ett Allow-huvud som anger listan över begärandemetoder som är godtagbara för den aktuella resursen. Eftersom PUT- och DELETE-metoderna skriver till resurser på servern har de flesta webbservrar inte stöd för eller tillåter dem som standard och returnerar ett 405-fel för sådana begäranden.
406 Innehållsegenskaperna för den begärda resursen uppfyller inte villkoren i begärans rubrik och en svarsenhet kan inte genereras. Om det inte är en HEAD-begäran ska svaret returnera en entitet som innehåller de lämpligaste entitetsegenskaperna och en lista med adresser som användaren eller webbläsaren kan välja mellan. Entitetens format bestäms av den mediatyp som definieras i Content-Type-headern. Webbläsaren kan göra det bästa valet baserat på formatet och sina egna möjligheter. I specifikationen definieras dock inga kriterier för att göra sådana automatiska val.
407 Liknar 401-svaret, förutom att klienten måste autentisera sig hos proxyservern. Proxyservern MÅSTE returnera ett Proxy-Authenticate för identitetsförfrågan. Klienten kan returnera en Proxy-Authorisation header för autentisering. Se RFC 2617.
408 Timeout för begäran. Klienten slutförde inte en begäran inom den tid som servern var beredd att vänta. Klienten kan när som helst skicka begäran på nytt utan att göra några ändringar.
409 Begäran kunde inte slutföras på grund av en konflikt med det aktuella tillståndet för den begärda resursen. Den här koden får bara användas om användaren anses kunna lösa konflikten och skicka en ny begäran. Svaret bör innehålla tillräckligt med information för att användaren ska kunna upptäcka källan till konflikten. Konflikter uppstår ofta vid behandlingen av PUT-begäranden. I en miljö med versionshantering bör t.ex. en PUT-begäran som skickas för att ändra en viss resurs med versionsinformation som står i konflikt med en tidigare begäran (från tredje part) returnera ett 409-fel som informerar användaren om att begäran inte kunde slutföras. I det här fallet kommer svarsenheten sannolikt att innehålla en jämförelse av skillnaderna mellan de två motstridiga versionerna, så att användaren kan skicka in den nya, sammanslagna versionen igen.
410 Den begärda resursen är inte längre tillgänglig på servern och det finns ingen känd vidarebefordringsadress. En sådan situation bör betraktas som permanent. Om möjligt bör klienter med länkredigeringsfunktioner ta bort alla referenser till denna adress med användarens tillstånd. Om servern inte vet eller inte kan avgöra om tillståndet är permanent bör en statuskod på 404 användas. Om inget annat anges kan detta svar cachas. Syftet med 410-svaret är främst att hjälpa webbmastern att underhålla webbplatsen genom att informera användaren om att resursen inte längre är tillgänglig och att serverägaren vill att alla fjärranslutningar till resursen också ska raderas. Den här typen av händelser är vanliga i tidsbegränsade mervärdestjänster. På samma sätt används 410-svaret för att meddela klienten att en resurs som tillhör en individ inte längre är tillgänglig på den aktuella serverplatsen. Frågan om alla resurser som är permanent otillgängliga måste markeras som sådana och hur länge de måste hållas på det sättet är naturligtvis också viktig.'410 Gone'， Det är helt upp till serverägaren att bestämma vad som ska gälla och hur länge det ska gälla.
411 Servern vägrar att acceptera förfrågningar utan att Content-Length-huvudet har definierats. Klienten kan skicka begäran på nytt efter att ha lagt till en giltig Content-Length-rubrik som anger längden på meddelandetexten i begäran.
412 Servern kunde inte uppfylla en eller flera av de förutsättningar som anges i begärans rubrikfält när begäran validerades. Denna statuskod gör det möjligt för klienten att ställa upp förhandsvillkor i metainformationen i begäran (data i fältet för begäran) när en resurs hämtas, och därmed förhindra att begäran tillämpas på andra resurser än det innehåll som önskas.
413 Servern vägrar att behandla den aktuella begäran eftersom den innehåller mer fysiska data än vad servern vill eller kan hantera. I så fall kan servern stänga anslutningen för att hindra klienten från att fortsätta att skicka begäran. Om situationen är tillfällig bör servern returnera en Retry-After-header för att informera klienten om hur mycket tid den har på sig att försöka igen.
414 URI:n för begäran är längre än vad servern kan tolka, så servern vägrar att hantera begäran. Detta är sällsynt och inträffar vanligtvis när en formulärinlämning som skulle ha använt POST-metoden blir en GET-metod, vilket resulterar i en lång frågesträng. "Svarta hål" i URI:er för omdirigeringar, till exempel att den gamla URI:n används som en del av den nya URI:n för varje omdirigering, vilket resulterar i en lång URI efter flera omdirigeringar. Klienter försöker attackera servrar genom att utnyttja säkerhetsbrister som finns i vissa servrar. Sådana servrar använder en buffert med fast längd för att läsa eller manipulera den begärda URI:n, vilket kan resultera i ett buffertöverflöd när GET-parametern överstiger ett visst värde, vilket leder till godtycklig kodkörning.[1]。 Servrar utan sådana sårbarheter bör returnera en statuskod på 414.
415 För den aktuella begärda metoden och den begärda resursen är den enhet som lämnas i begäran inte i ett format som stöds av servern och begäran avvisas.
416 Om begäran innehåller en Range-begäranderubrik och de dataintervall som anges i Range inte sammanfaller med de intervall som är tillgängliga för den aktuella resursen och begäran inte innehåller någon If-Range-begäranderubrik, ska servern returnera en statuskod 416. Om Range använder byteintervall betyder detta att den första byten i alla de dataintervall som anges i begäran överskrider längden på den aktuella resursen. Servern bör också inkludera en Content-Range entity header som anger längden på den aktuella resursen tillsammans med statuskoden 416. Det är också förbjudet att använda multipart/byteranges som Content-Type i detta svar.
417 Det förväntade innehåll som anges i begärans rubrik Expect kan inte uppfyllas av servern, eller så är servern en proxyserver som har tydliga bevis för att innehållet i Expect inte kan uppfyllas vid nästa nod i den aktuella rutten.
421 Antalet anslutningar till servern från den aktuella klientens IP-adress överskrider det högsta antal som tillåts av servern. Normalt avser IP-adressen här klientens adress sedd från servern (t.ex. användarens gateway- eller proxyserveradress). I det här fallet kan mer än en slutanvändare vara inblandad i anslutningsräkningen.
422 Antalet anslutningar från den aktuella klientens IP-adress till servern överskrider det högsta antal som tillåts av servern. Med IP-adress avses här vanligen klientens adress sett från servern (t.ex. användarens gateway- eller proxyserveradress). I det här fallet kan mer än en slutanvändare vara inblandad i anslutningsräkningen.
422 Begäran var korrekt formaterad, men kunde inte besvaras eftersom den innehöll semantiska fel. (RFC 4918 WebDAV) 423 Locked Den aktuella resursen är låst. (RFC 4918 WebDAV) 423 Låst
424 Den aktuella begäran misslyckades på grund av ett fel i en tidigare begäran, t.ex. PROPPATCH. (RFC 4918 WebDAV)
425 Definieras i utkastet till WebDav Advanced Collections, men förekommer inte i WebDAV Sequential Collections Protocol (RFC 3658).
426 Klienter bör byta till TLS/1.0. (RFC 2817)
449 Utökad av Microsoft för att representera att förfrågningar ska prövas igen efter att lämplig åtgärd har utförts.
500 Servern stötte på ett oförutsett problem som hindrade den från att slutföra behandlingen av begäran. Vanligtvis uppstår detta problem när det finns ett fel i serverns programkod.
501 Servern har inte stöd för en funktion som krävs för den aktuella begäran. När servern inte känner igen den begärda metoden och inte kan stödja dess begäran om någon resurs.
502 En server som fungerar som gateway eller proxy får ett ogiltigt svar från en uppströmsserver när den försöker utföra en begäran.
503 Servern kan för närvarande inte behandla begäran på grund av tillfälligt serverunderhåll eller överbelastning. Detta tillstånd är tillfälligt och kommer att återställas efter en tid. Om en fördröjning kan förväntas kan svaret innehålla en Retry-After-header som anger fördröjningen. Om denna Retry-After-information inte ges bör klienten hantera det på samma sätt som ett 500-svar. Observera: Att statuskoden 503 finns betyder inte att servern måste använda den om den är överbelastad. Vissa servrar vill helt enkelt neka klienten en anslutning.
504 En server som fungerar som gateway eller proxy och som försöker utföra en begäran får inte ett svar i rätt tid från en uppströmsserver (en server som identifieras av en URI, t.ex. HTTP, FTP, LDAP) eller en sekundärserver (t.ex. DNS). Obs: Vissa proxyservrar returnerar ett 400- eller 500-fel när DNS-uppslagningen tar slut.
505 Servern stöder inte, eller vägrar att stödja, den version av HTTP som används i begäran. Detta innebär att servern inte kan eller vill använda samma version som klienten. Svaret bör innehålla en enhet som beskriver varför versionen inte stöds och vilka protokoll som servern stöder.
506 Utökad av Transparent Content Negotiation Protocol (RFC 2295) för att representera en intern felkonfiguration från serverns sida: den begärda Negotiation Variant-resursen är konfigurerad för att använda sig själv i Transparent Content Negotiation och är därför inte ett lämpligt fokus i en förhandlingsprocess.
507 Servern kan inte lagra det innehåll som krävs för att uppfylla begäran. Detta tillstånd anses vara tillfälligt.WebDAV(RFC 4918)
509 Servern har nått sin bandbreddsgräns. Detta är inte en officiell statuskod, men används fortfarande i stor utsträckning.
510 Den policy som krävs för att erhålla resursen har inte uppfyllts. (RFC 2774)
Åtkomstloggar:

Samling av online-verktyg