| Http status kod | 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-meddelanderubriken att den ska använda ett annat protokoll för att slutföra begäran. Efter att ha skickat den sista tomma raden i detta svar kommer servern att byta till de protokoll som definieras i Upgrade-meddelanderubriken. Detta bör endast göras om det är mer fördelaktigt att byta till ett nytt protokoll. 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 realtids- och synkronprotokoll för att leverera resurser som utnyttjar sådana funktioner. |
| 102 | Statuskoder, utökade av WebDAV (RFC 2518), representerar att bearbetningen kommer att fortsätta. |
| 200 | Begäran har lyckats och den svarsrubrik eller datahelhet som begärdes av begäran kommer att returneras med detta svar. |
| 201 | Begäran har uppfyllts och en ny resurs har skapats enligt begäran och dess URI har returnerats med Location-headern. Om den begärda resursen inte kan skapas i tid ska "202 Accepted" returneras. |
| 202 | Servern har accepterat begäran, men har ännu inte behandlat den. Precis som den kan avvisas, kan begäran i slutändan komma att utföras eller inte. I samband med asynkrona operationer finns det inget bekvämare än att skicka denna statuskod. Syftet med att returnera ett svar med statuskoden 202 är att göra det möjligt för servern att acceptera förfrågningar från andra processer (t.ex. en batchbaserad operation som bara utförs en gång om dagen) utan att behöva hålla klienten ansluten till servern tills batchoperationen är helt slutförd. Ett svar som accepterar en begäran om bearbetning och returnerar en statuskod 202 BÖR i den returnerade entiteten innehålla viss information som anger processens aktuella status, samt en pekare till en statusmonitor eller statusförutsägelse så att användaren kan uppskatta om operationen har slutförts. |
| 203 | Servern har 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 originalversionen. Metadata som innehåller resurser kan t.ex. leda till att originalservern känner till metainformationen 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 sådana rubriker 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 har behandlat begäran och inte returnerat något. Till skillnad från 204-svaret ber dock svaret 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 meddelandekropp och avslutas 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 ett stort dokument i flera nedladdningssegment samtidigt. Begäran måste innehålla ett Range-huvud för att ange det innehållsintervall som klienten vill ta emot och kan innehålla ett 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; vid nedladdning av flera segment med en Content-Type av typen multipart/byteranges bör varje multipartsegment innehålla ett Content-Range-fält som anger omfattningen av innehållet i det segmentet. Om svaret innehåller en Content-Length måste dess värde motsvara det verkliga antalet byte i det innehållsintervall som returneras. date ETag och/eller Content-Location, om samma begäran borde ha returnerat ett svar på 200. Expires, Cache-Control och/eller Vary, om deras värden kan skilja sig från andra svar med samma variabler. Expires, Cache-Control och/eller Vary, om deras värden kan skilja sig från värdena i andra tidigare svar för samma variabler. Detta svar BÖR INTE innehålla andra entitetsrubriker om begäran använder stark cachevalidering enligt If-Range och BÖR INTE innehålla andra entitetsrubriker om begäran använder svag cachevalidering enligt If-Range; på så sätt undviks inkonsekvenser mellan cachelagrat entitetsinnehåll och uppdaterad entitetsrubriksinformation. I annat fall SKA detta svar innehålla alla de entitetshuvudfält som skulle ha returnerats i alla de 200-svar som skulle ha returnerats. Om ETag- eller Last-Modified-rubrikerna inte matchar exakt, SKA cacheminnet på klientsidan förbjuda att innehållet som returneras i svar 206 kombineras med något tidigare cachat innehåll. En cache som inte stöder rubrikerna Range och Content-Range får inte cachelagra det innehåll som returneras i svaret 206. |
| 207 | Statuskoden, som utökats av WebDAV (RFC 2518), 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 underfrågor. |
| 300 | Den begärda resursen har en rad alternativa returmeddelanden, vart och ett med sin egen specifika adress och webbläsarstyrd förhandlingsinformation. Användaren eller webbläsaren kan själv 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 ett sådant automatiskt val ska göras. Om servern själv redan har ett föredraget val av svar, bör URI:n för detta svar anges i Location; webbläsaren kan använda detta Location-värde som adress för automatisk omdirigering. Dessutom är detta svar också 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 är det därför förbjudet för webbläsaren att 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 en GET. |
| 302 | Den begärda resursen svarar nu tillfälligt på begäran från en annan URI. Eftersom omdirigeringen är tillfällig bör klienten fortsätta att skicka framtida begäranden 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 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 RFC 1945- och RFC 2068-specifikationerna inte tillåter klienten att ändra metoden för begäran vid omdirigering, 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 alternativ referens till den ursprungliga resursen. Dessutom är det förbjudet att cachelagra 303-svaret. 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 svarsenheten innehålla en hyperlänk till den nya URI:n och en kort beskrivning. Observera: Många webbläsare före HTTP/1.1-versioner förstår inte 303-läget korrekt. Om interaktion med dessa webbläsare måste övervägas bör statuskoden 302 räcka, eftersom de flesta webbläsare behandlar 302-svar på exakt samma sätt som ovanstående specifikation kräver att klienten gör när den behandlar ett 303-svar. |
| 304 | Servern BÖR returnera denna statuskod om klienten skickar en villkorlig GET-begäran som har tillåtits och innehållet i dokumentet (sedan det senaste besöket eller enligt villkoren för begäran) inte har ändrats.304 Svar får inte innehålla någon meddelandekropp och slutar därför alltid med den första tomma raden efter meddelandehuvudet. Svaret MÅSTE innehålla följande rubriker: Date, såvida inte servern saknar klocka. Om en server utan klocka följer dessa regler kan proxyservern och klienten själva lägga till fältet Date i det inkommande svarets rubrik (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 Expires, Cache-Control och/eller Vary, om värdet kan skilja sig från det värde som motsvarar andra tidigare svar för samma variabel. Om denna svarsförfrågan använder stark cache-validering bör detta svar inte innehålla andra entitetsrubriker; i annat fall (t.ex. en villkorlig GET-förfrågan använder svag cache-validering) är det förbjudet för detta svar att innehålla andra entitetsrubriker; detta undviker inkonsekvenser mellan cachat entitetsinnehåll och uppdaterad entitetsrubriksinformation. Om ett 304-svar anger att en entitet för närvarande inte är cachelagrad måste cachelagringssystemet 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 den angivna proxyn. fältet Location ger information om den URI där den angivna proxyn finns. mottagaren skulle behöva skicka en separat begäran upprepade gånger för att komma åt 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 den ursprungliga servern. 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 | Den begärda resursen svarar nu tillfälligt på begäran från en annan URI. Eftersom sådana omdirigeringar är tillfälliga 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 måste ovanstående information läggas till 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 detta, eftersom villkoren för begäran kan ändras. |
| 400 | 1. Det finns ett semantiskt fel och den aktuella begäran kan inte förstås av servern. Om den inte ändras bör klienten inte skicka denna begäran upprepade gånger. 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 upprepade gånger skicka en begäran som innehåller lämplig information i Authorisation-headern. Om den aktuella begäran redan innehåller autentiseringsuppgifter innebär 401-svaret 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 försökt autentisera minst en gång, SKA webbläsaren visa användaren den enhetsinformation som finns i svaret, eftersom denna enhetsinformation 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 denna begäran bör inte skickas på nytt. Om detta inte är en HEAD-begäran och servern vill kunna tala klarspråk om varför begäran inte kan utföras, bör orsaken till vägran beskrivas inom entiteten. Naturligtvis kan servern också returnera ett 404-svar om den inte vill ge klienten 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 användaren 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 resursen på servern stöder de flesta webbservrar inte dessa begärandemetoder eller tillåter dem inte som standard, och kommer att returnera 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 en lista med entitetsegenskaper och adresser från vilken användaren eller webbläsaren kan välja den lämpligaste entiteten. Entitetens format bestäms av den mediatyp som definieras i rubriken Content-Type. Webbläsare kan göra sina egna bästa val 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 på proxyservern. Proxyservern MÅSTE returnera ett Proxy-Authenticate för identitetsförfrågan. Klienten KAN returnera en Proxy-Authorization header för autentisering. Se RFC 2617. |
| 408 | Timeout för begäran. Klienten slutförde inte sändningen av 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 vanligtvis vid behandlingen av PUT-begäranden. Om t.ex. versionsinformationen i en PUT-begäran som skickas för att ändra en viss resurs står i konflikt med en tidigare begäran (från tredje part) i en miljö med versionshantering, bör servern 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 versionen igen efter sammanslagningen. |
| 410 | Den begärda resursen är inte längre tillgänglig på servern och har inte någon känd vidarebefordringsadress. Ett sådant tillstånd 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 detta tillstånd är permanent, bör en statuskod på 404 användas. Om inget annat anges kan detta svar cachas.410 Syftet med 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 tas bort. 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 klienter att en resurs som ursprungligen tillhörde en person på den aktuella serverns webbplats inte längre är tillgänglig. Det är naturligtvis helt upp till serverägaren att avgöra om alla permanent otillgängliga resurser måste markeras som "410 Gone" och hur länge denna markering måste upprätthållas. |
| 411 | Servern vägrar att acceptera förfrågningar utan att Content-Length-huvudet har definierats. Efter att ha lagt till en giltig Content-Length-rubrik som anger längden på meddelandetexten kan klienten skicka begäran igen. |
| 412 | Servern kunde inte uppfylla en eller flera av förutsättningarna när den kontrollerade att de angavs i begärans rubrikfält. Denna statuskod gör det möjligt för klienten att ställa upp förhandsvillkor i begärans metameddelande (data i fältet för begärans rubrik) när en resurs hämtas, och därmed förhindra att begärans metod 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 entitetsdata som är större än vad servern vill eller kan hantera. I detta fall kan servern stänga anslutningen för att förhindra att klienten fortsätter att skicka denna begäran. Om detta tillstånd är tillfälligt bör servern returnera ett Retry-After-svarshuvud för att informera klienten om hur lång tid det tar innan den kan försöka igen. |
| 414 | Längden på begärans URI överskrider den längd som servern kan tolka, så servern vägrar att hantera begäran. Detta är sällsynt och inträffar ofta när ett formulär som skulle ha skickats in med POST-metoden istället skickas in med GET-metoden, 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 vid 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 URI:n för en begäran, och när parametrarna efter en GET överstiger ett visst värde kan ett buffertöverflöd uppstå, vilket leder till att godtycklig kod kan exekveras [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, så begäran avvisas. |
| 416 | Om begäran innehåller en Range-begäranderubrik och eventuella dataområden som anges i Range inte överlappar de områden som är tillgängliga för den aktuella resursen och If-Range-begäranderubriken inte definieras i begäran, ska servern returnera en statuskod 416. Om Range använder byteintervall är detta fallet om den första bytepositionen 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 denna server 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 IP-adress där den aktuella klienten befinner sig överskrider det högsta antal som tillåts av servern. Med IP-adress avses här vanligtvis klientens adress sett från servern (t.ex. användarens gateway- eller proxyserveradress). I det här fallet kan antalet anslutningar omfatta mer än en slutanvändare. |
| 422 | Antalet anslutningar till servern från den aktuella klientens IP-adress ö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 antalet anslutningar omfatta mer än en slutanvändare. |
| 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) |
| 424 | Den aktuella begäran misslyckades på grund av ett fel som inträffade i en tidigare begäran, till exempel 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 bör 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 viss funktion som krävs för den aktuella begäran. När servern inte kan känna 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 innehållsförhandling 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 slutföra 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 uppfylldes inte. (RFC 2774) |