| HTTP-tilakoodi |
Tilakoodin merkitys |
| 100 |
Asiakkaan tulisi jatkaa pyynnön lähettämistä. Tämä väliaikainen vastaus ilmoittaa asiakkaalle, että osa pyynnöstä on vastaanotettu ja se ei ole vielä hylätty. Asiakkaan tulisi jatkaa pyynnön loppuosan lähettämistä, tai, jos pyyntö on jo valmis, muistaa tämä vastaus. |
| 101 |
Palvelin on ymmärtänyt asiakkaan pyynnön ja ilmoittaa asiakkaalle, että se aikoo käyttää eri protokollaa pyynnön suorittamiseen Upgrade-otsikon kautta. Viimeisen tyhjän rivin lähettämisen jälkeen palvelin siirtyy niihin protokolliin, jotka on määritelty Upgrade-otsikossa. Samankaltaisia toimenpiteitä tulisi noudattaa ainoastaan, kun vaihto uuteen protokollaan on edullisempaa. Esimerkiksi, uuden HTTP-version siirtäminen vanhasta versioista on edullisempaa, tai siirtyminen reaaliaikaiseen ja synkronoitavaan protokollaan niiden resurssien siirtämiseksi, etersä tällä tavalla. |
| 102 |
WebDAV (RFC 2518) -standardin laajennettu tilakoodi, joka edustaa, että käsittelyä jatketaan. |
| 200 |
Pyyntö on onnistunut, pyyntöä toivottu vastaus tai tietosisältö palautetaan tämän vastauksen mukana. |
| 201 |
Pyyntö on toteutettu, ja uusi resurssi on luotu pyyntöä varten, ja sen URI on palautettu Location-otsikossa. Jos tarvittavaa resurssia ei voida luoda nopeasti, tulisi palauttaa '202 Hyväksytty'. |
| 202 |
Palvelin on hyväksynyt pyynnön mutta ei ole vielä käsitellyt sitä. Kuten se voi tulla hylätyksi, pyyntö voidaan myös toteuttaa tai ei. Asynkronisessa toimintaympäristössä ei ole keinoa tehdä pyynnöstä tätä helpompaa. Tämä koodi palvelee tarkoittamaan, että palvelin voi hyväksyä muiden prosessien pyynnöt (esimerkiksi perusprosessi, joka suoritetaan vain kerran päivässä) ilman, että asiakkaan on pakko pitää yhteyttä palvelimeen kunnes prosessointi on suoritettu. Vastauksen pitäisi sisältää joitakin ohjeita, joissa tiedotetaan, missä prosessoinnin tila on tällä hetkellä. |
| 203 |
Palvelin on onnistuneesti käsitellyt pyynnön, mutta palautettu entiteettiotsikon meta-informaatio ei ole erityinen yhteensopiva alkuperäisen palvelimen kanssa, vaan on paikallinen tai kolmannen osapuolen kopio. Nykyinen informaatio voi olla osa alkuperäisestä versiosta tai täydellinen joukko. Esimerkiksi, resurssin metadatat voivat saada alkuperäisen palvelimen tietämään superinformaatiosta. Tämän tilakoodin käyttö ei ole pakollista, ja se on vain sopivaa, jos vastaus ei käyttäisi tätä koodia, vaan palauttaisi 200 Hyväksytty. |
| 204 |
Palvelin on onnistuneesti käsitellyt pyynnön, mutta ei tarvitse palauttaa yhtaän sisältöä, ja haluaisi palauttaa päivitetyt meta-informaatiot. Vastaus voi palauttaa uusia tai päivitettyjä meta-informaatiota entiteettiotsikon muotona. Jos tällaisia otsikoita on olemassa, niiden tulee vastata pyydettyjä muuttujia. Jos asiakas on selain, sen tulisi säilyttää pyyntöä lähettäneet sivut olematta muutosta asiakirjan näkymässä, vaikka säännöissä sanotaan, että uusia tai päivitettäviä meta-informaatiota pitäisi käyttää käyttäjän selaimen aktiivisessa asiakirjan näkymässä. Koska 204-vastausta ei voida lähettää viestikunnossa, se loppuu aina ensimmäisen tyhjän rivin jälkeen viestipään jälkeen. |
| 205 |
Palvelin on onnistuneesti käsitellyt pyynnön, mutta ei palauta mitään sisältöä. Kuitenkin 204-vastauksen myötä tämä koodi vaatii pyytäjän palauttamaan asiakirjan näkymän. Tämä vastaus on ensisijaisesti tarkoitettu käyttäjän syötteiden vastaanottamiseen ja asiakirjan nollaamiseen niin, että käyttäjä voi aloittaa seuraavan syötteen. Kuten 204-vastaus, tämä vastaus on myös kielletty palauttamasta viestikuntaa ja päättyy ensimmäiseen tyhjään rivin. |
| 206 |
Palvelin on jo onnistuneesti käsitellyt osan GET-pyynnöistä. Tällaisia vastauksia käytetään FlashGetin tai Wondrous-downloaderin kaltaisten HTTP-lataustyökalujen osalta, tuottamaan katkottuja latauksia tai jakamaan suuri asiakirja useisiin osiin samanaikaiseksi lataamiseksi. Pyyntö on sisältänyt Range-otsikon, joka osoittaa asiakkaalle, mitä sisältöä se haluaisi. Vastaus on pakko sisältää seuraavat otsikot: Content-Range, joka osoittaa tämän vastauksen sisältämän sisällön alueen; ja jos Content-Type on multipart/byteranges, jokaisessa osiossa on oltava Content-Range, joka osoittaa tämän osan sisältöalueen. Jos vastauksessa on Content-Length, sen arvo on pakko vastata sen alueen aitoja tavuja, jotka palautetaan; ETag ja/tai Content-Location, jos samanlainen kysely pitäisi myös palauttaa 200-vastaus. Expires, Cache-Control, ja/tai Vary, jos niiden arvo voi poiketa aikaisemmista arvoista, jotka liittyvät muuhun oikeaan muuttujaan. Jos tämän vastauksen pyyntö käytti If-Rangea, niin tämä vastaus ei saa sisältää mitään muita entiteettiotsikoita; jos pyyntö käytti If-Range-reilua välimuistia, niin tämä vastaus saa olla ilman muita entiteettiotsikoita; tämä estää välimuistissa olevan entiteetti koetuksen ja päivityksellisten otsikoiden eron. Muuten, tämä vastaus on pakko sisältää kaikki otsikot, jotka olisivat olleet vastuissa, jotka pitäisi palauttaa 200-vastauksessa. Jos ETag tai Last-Modified otsikot eivät täsmä toisiinsa, asiakastietokannan täytyy estää 206-vastauksessa olevan sisällön yhteensovittaminen aikaisemmin tallentamiinsa. Yksikään välimuisti, joka ei tue Rangea ja Content-Rangea, ei saa tallentaa 206-vastauksessa olevan sisällön. |
| 207 |
WebDAV (RFC 2518) -standardin laajennettu tilakoodi, joka kertoo, että seuraava viestikunta on XML-viesti, ja se voi sisältää useita erillisiä vastauskoodeja aikaisemman alipyynnön määrästä riippuen. |
| 300 |
Pyydetyllä resursilla on useita vaihtoehtoisia vastauksia, joilla kaikilla on omat erityiset osoitteensa ja selainohjausviestinsä. Käyttäjä tai selain voi valita haluamansa osoitteen uudelleenohjaukseen. Ellei tämä ole HEAD-pyyntö, tämän vastauksen tulisi sisältää entiteetti, joka sisältää resurssin erityisarvot ja osoiteluettelon, jotta käyttäjä tai selain voi valita parhaan uudelleenohjausosoitteen. Tämän entiteetin muoto määrittelee Content-Typen määrittelemä muodossa. Selain voi automaattisesti tehdä parhaan päätöksen riippuen vastauksen muotoa ja selaimen kyvykkyyttä. Tietenkään RFC 2616 -standardi ei ole määritellyt, miten automaattinen valintaan olisi pitänyt tapahtua. Jos palvelimella on oma suositeltu vastaus, tämän vastaus-URI:n on kyettävä osoittamaan Locationissa, selain voi kenties ottaa tämän Location-arvon automaattisen uudelleenohjauksen osoitteeksi. Lisäksi, jollei erikseen toisin ilmoiteta, tämä vastaus on myös välimuistissa. |
| 301 |
Pyydetty resurssi on pysyvästi siirretty uuteen sijaintiin, ja tulevaisuudessa kaikki viittaukset tähän resurssiin tulisi käyttää tämän vastauksen mukaan palautettavan yhden tai useamman URI:n. |
| 302 |
Pyydetty resurssi on tällä hetkellä tilapäisesti siirretty eri URI:sta. Koska tällainen uudelleenohjaus on väliaikainen, asiakkaan tulisi lähettää tulevat pyynnöt alkuperäiseen osoitteeseen. Tämä vastaus voi olla välimuistissa vain, jos Cache-Control tai Expires on asianmukaisesti määritelty. Uuden väliaikaiseen URI:in tunnistamisen on oltava Location-otsikossa. |
| 303 |
Vastaus nykyiseen pyyntöön voidaan löytää toisessa URI:ssa, ja asiakkaan tulisi käyttää GET-menetelmää päästäkseen tuohon resurssiin. Tämän menetelmän olemassaolo on suunniteltu mahdollistamaan skriptivoittoisten POST-pyyntöjen uudelleenohjauksen uuteen resurssiin. Tämä uusi URI ei ole alkuperäisen resurssin korvaava viite. Samalla, 303-vastausta ei saa välimuistissa. Tietenkin, toinen pyyntö (uudelleenohjaus) voi olla välimuistissa. Uuden URI:in pitäisi löytyä Location-otsikosta. Ellei tämä ole HEAD-pyyntö, vastausmateriaalin on oltava mukana uusi URI:n hyperlinkki ja lyhyt kuvaus. Huomaa: monet ennen HTTP/1.1 -versioita olevat selaimet eivät voi ymmärtää 303-tilakoodia oikein. Mikäli on tarpeen ottaa huomioon vuorovaikutus näiden selainten kanssa, 302-tilakoodia tulisi käyttää, koska useimmat selaimet käsittelevät 302-vastauksia juuri kuten yllä on toimitettu asiakkaan tulisi käsitellä 303-vastauksia. |
| 304 |
Jos asiakas on lähettänyt ehdollisen GET-pyynnön, ja tämä pyyntö on sallittu, eikä asiakirjan sisältö (kun sitä on viimeksi kysytty tai sen ehtojen mukaan) ole muuttunut, niin palvelimen tulisi lähettää tämä tilakoodi. 304-vastaus ei saa sisältää viestikuntaa, joten se loppuu aina ensimmäisen tyhjän rivin jälkeen viestipään jälkeen. Tämän vastauksen on oltava seuraavat otsikot: Date, elletä palvelimella ei ole kelloa. Jos kelloa ei ole, ja palvelin noudattaa näitä sääntöjä, agentti ja asiakas voivat itse lisätä Date-kentän vastaanotettuihin vastaukseen (kuten RFC 2068:ssa on säädetty), välimuistimekanismi tulee toimimaan. ETag ja/tai Content-Location, elletteistä pyyntö olisi pitänyt palauttaa 200-vastauksen. Expires, Cache-Control ja/tai Vary, jos niiden arvo voi poiketa aikaisemmista saman muuttujan muista vastauksista. Jos tämän vaste-pyyntö käytti syrjäyttävää välimuistia, niin tätä vastausta ei saa sisältää muuta entiteettiotsikkoa; ellei (esimerkiksi, kun ehdollinen GET-pyyntö käytti pehmeää välimuistia) tälle vastaukselle kiellettyyn välimuistiin sisältyy muita entiteettiotsikoita; tämä estää välimuistissa olevan yhtenäisen entiteettiä ja päivityssuunnitelossa olevaa eroa. Jos 304-vastaus ilmoittaa, että nykyinen resurssi ei ole välimuistissa, välimuistit järjestelmät on käytettävä huomiota, ja ne varmistaavat ensimmäinen pyyntö ilman mistään rajoitusratkaisuista. Jos vastaanotetaan 304-vastaus, joka vaatii päivittää tietyn välimuistille, silloin kaikki päivitettävät kentät on säilytettävä, jotka ovat edellisissä requistet ja ovat tullut keskiarvona. |
| 305 |
Pyydetyn resurssin pääsy vaatii määritellyn välikäytännön käyttöä. Location-otsikko on ilmoitettu, ja saajan on toistettava uusi pyyntö tämän välikäytännön kautta voidakseen käyttää vastaavaa resurssia. Vain alkuperäinen palvelin voi toimittaa 305-vastaussekun. Huomaa: RFC 2068:ssa ei ole selvitetty, että 305-vastaus on käytettävä yksittäisten pyyntöjen uudelleenohjaukseen, ja sen on oltava vain alkuperäisen palvelimen tuottama. Unohtaminen tämän lohkon voi johtaa vakaviin turvallisuushäiriöihin. |
| 306 |
Uusimmassa säännöksessä 306-tilakoodia ei enää käytetä. |
| 307 |
Pyydetty resurssi on tällä hetkellä tilapäisesti siirretty eri URI:sta. Koska tällainen uudelleenohjaus on väliaikainen, asiakkaan tulisi lähettää tulevat pyynnöt alkuperäiseen osoitteeseen. Tämä vastaus voi olla välimuistissa vain, jos Cache-Control tai Expires on asianmukaisesti määritelty. Uuden väliaikaiseen URI:in tunnistamisen on oltava Location-otsikossa. Ellei tämä ole HEAD-pyyntö, vastausmateriaalin on oltava mukana uusi URI:n hyperlinkki ja lyhyt kuvaus. Koska osa selaimista ei täsmää 307-vastausta, on tärkeää lisätä nämä tiedot, jotta käyttäjä voi ymmärtää ja tehdä uuden pyyntö uuden URI:n kohdalla. Ellei tämä ole GET tai HEAD-pyyntö, selain estää automaattisen uudelleenohjauksen, ellette olennaisesti vahvisteta asiasta, koska pyynnön ehto voinee vaihtua. |
| 400 |
1. Semanttinen virhe, nykyinen pyyntö ei ole ymmärrettävä palvelimella. Ellei muokattu, asiakas ei pitäisi toistaa tätä pyyntöä uudelleen. 2. Pyyntöparametreissa on virhe. |
| 401 |
Nykyinen pyyntö vaatii käyttäjän todennusta. Tämän vastauksen on sisällettävä WWW-Authenticate-tietotuki, joka kysyy käyttäjätietoja. Asiakas voi toistaa pyynnön, joka sisältää sopivan Authorization-otsikon. Jos nykyinen pyyntö on jo sisältänyt todennustodistuksia, niin 401-vastaus merkitsee, että palvelin on hylännyt todennustodistukset. Jos 401-vastaus sisältää identtisiä autentikointikysymyksiä aikaisemman vastauksen osalta, ja selain on kokeillut vähintään kerran vahvistaan, se tulisi näyttää käyttäjälle, koska näissä tietoisissa olosuhteissa voi olla merkityksellisiä diagnoositietoja. Katso RFC 2617. |
| 402 |
Tämä koodi on varattu tulevia mahdollisia tarpeita varten. |
| 403 |
Palvelin on ymmärtänyt pyynnön, mutta on kieltäytynyt suorittamasta sitä. Toisin kuin 401-vastaus, autentikoinnista ei ole apua, eikä tätä pyyntöä tulisi toistaa. Jos tämä ei ole HEAD-pyyntö, ja palvelin haluaa selittää, miksi pyyntö ei voida suorittaa, se on kuvattava sisällön aikana. Tietenkin palvelin voi myös palauttaa 404-vastauksen, jos se ei toivo, että asiakas saisi mitään tietoa. |
| 404 |
Pyyntö epäonnistui, pyydetty resurssi ei löytynyt palvelimelta. Ei ole tietoa, joka kertoisi käyttäjälle, onko tilanne tilapäinen vai pysyvä. Jos palvelin tietää tilanteen, sen tulisi käyttää 410-tilakoodia ilmoittaakseen, että vanha resurssi ei ole enää käytettävissä jonkin sisäisen kokoonpanomekanismiongelman vuoksi ja että ei ole olemassa erityistä ohiria. 404-tilakoodia käytetään laajalti, kun palvelin ei halua paljastaa syitä siihen, miksi pyyntö kieltäytyy tai ei ole muita sopivia vastauksia saatavilla. |
| 405 |
Pyynnön kohdalla määriteltyä menetelmää ei voida käyttää pyydetyn resurssin käyttäminen. Tämän vastauksen on palautettava Allow-otsikko ilman muuta, jotta voidaan määrittää luettelo tämän resurssin hyväksymistä menetelmistä. Koska PUT- ja DELETE-menetelmät suorittaa kirjoituksia palvelimella oleviin resursseihin, useimmat verkkopalvelimet eivät tue tai eivät automaattisesti salli kyseisiä pyynnön tyyppejä, ja tuottaa 405-virheitä. |
| 406 |
Pyydetyn resurssin sisältöominaisuudet eivät voi täyttää pyyntöotsikoiden ehtoja, joten ei ole mahdollista tuottaa vastauksen sisältöä. Ellei tämä ole HEAD-pyyntö, tämän vastauksen tulisi palauttaa entiteetti, joka voi antaa käyttäjälle tai selaimelle parhaan valinnan sisältöominaisuuksista ja osoitteista. Entiteetin muoto määräytyy Content-Type-otsikon mukaisesti. Selain voi automaattisesti valita parhaan sisällön muotojen mukaan ja sen kyvyn mukaan. Täsmällistä ei ole määritelty, miten tällainen automaattinen valinta määritellään säännöissä. |
| 407 |
Vastaava 401, mutta asiakkaan on suoritettava todennus välityspalvelimella. Välityspalvelimen on palautettava Proxy-Authenticate kysellen. Asiakas voi lähettää Proxy-Authorization-tieto-otsikon toteaakseen. Katso RFC 2617. |
| 408 |
Pyyntö aikakatkaistu. Asiakas ei ole jättänyt pyyntöään palvelimen odotusaikana. Asiakas voi lähettää tämän pyynnön uudelleen ilman muutoksia. |
| 409 |
Pyyntö ei voi toteutua, koska se on ristiriidassa pyydetyn resurssin nykyisen tilan kanssa. Tämän koodin käyttö on sallittua vain, jos käyttäjää voidaan pitää voivana ratkaista ristiriita, ja hänellä on mahdollisuus lähettää uusi pyyntö. Tämän vastauksen tulisi sisältää riittävästi tietoa käyttäjän löytää ristiriidan alkuperä. Ristiriidat esiintyvät yleensä PUT-pyyntöjen käsittelyssä. Esimerkiksi, jos versiointikontrollin ympäristössä tietyt PUT-pyynnöt, joissa on ketjunomaisia samalla resurssilla käytettyjä versio-muuttujia, saattaisi kohdata ristiriidan, palvelimen tulisi palata 409-virhe ja kertoa käyttäjälle, ettei pyyntöä voi toteuttaa. Tällöin vastauksen entiteetti voi sisältää kahden ristiriitaisen version välinen vertailu, jotta käyttäjä voi yhdistää uuden version. |
| 410 |
Pyydetty resurssi ei ole enää käytettävissä palvelimella, eikä tiedetään enää siirrettävänä osoitteena. Tällainen tilanne pitäisi katsoa pysyväksi. Jos vain tila on käyttöoikeuksilla, asiakkaan olisi poistettava kaikki viittaukset tälle osoitteelle käyttäjän hyväksynnällä. Jos palvelin ei tiedä tai ei voi tarkistaa, onko tämä tilanne pysyvä, niin käytetään 404-tilakoodia. Jollei erikseen mainita, tämä vastaus on välimuistittava. 410-vastaus on tarkoitettu auttamaan verkkosivuston omistajia, jolla on tieto, että resurssi ei ole enää käytettävissä, ja palvelimen omistaja toivookin, että kaikki tätä resurssia kohti olevan etäyhteyden on poistettava. Tälläisiä tapahtumia esiintyy erityisesti rajoitetuissa ja etu alennuspalveluissa. Samoin 410-vastausta käytetään ilmoituksena asiakkaille, että nykyisellä palvelinsivustolla aikaisemmin henkilökohtaisia resursseja ei enää ole käytettävissä. Toki on palvelimen omistajan yksinomainen valinta, pitäisikö kaikki pysyvästi käytettävissä olevat resurssit merkitä 410 Gone ja kuinka kauan se pitäisi pitää. |
| 411 |
Palvelin kieltäytyy hyväksymästä pyyntöä, ellette Content-Length-otsikkoa ole määritelty. Kun validoimisena oleva Content-Length-otsikko on lisätty, asiakas voi uudelleen jättää tämän pyynnön. |
| 412 |
Palvelin ei voi toteuttaa voitteet ehtoja, jotka on määritelty pyyntöotsikoissa. Tämä tilakoodi sallii asiakkaan asettaa mailoita ehtoja ennen resurssin saamista pyyntöotsikoissa, jotta hän ei käytä pyyntöjen tiloja muilla kuin toivottajille. |
| 413 |
Palvelin kieltäytyy käsittelemästä nykyistä pyyntöä, koska lähetetty entiteettidatan koko ylittää palvelimen hyväksymänä mahdollisen alueen. Jos tämä tosiasia on tilapäinen, palvelin voi sulkea yhteyden estääkseen asiakasta jatkamasta tämän pyynnön toimintaa. Jos tämä tilanne on tilapäinen, palvelin tulisi palauttaa Retry-After-otsikko, joka ilmoittaa asiakkaalle, kun on mahdollista kokeilla uudelleen. |
| 414 |
Pyydetyn URI:n pituus ylittää palvelimen kyvyn ymmärtää sen pituuden, joten palvelin kieltäytyy palvelemasta tätä pyyntöä. Tämä on harvinainen tilanne, joka tapahtuu yleensä kun POST-menettelyä käytetään, ja se muuttuu GET-menettelyksi, mikä johtaa pitkään kyselymerkkijonoon. URI -kysely "mustaan aukkoon", jossa jokaisella uudelleenohjauksella on uusi URI vanhan ylimmäisenä osana, jolloin useat uudelleenohjaukset johtavat URI:n pidentymiseen. Asiakas yrittää hyödyntää tiettyjä palvelimia hyökkäämään palvelimea kohtaan. Tällaiset palvelimet käyttävät vahvistettuja pituuksia pituuden ja mittausvirheiden käsittämiseen ja voivat ylittää koko seisonta-aikaansa, mikä aiheuttaa ylivuotoa, mikä voi johtaa epätoivottaviin ohjelmakoodeihin[1]. Ilman näitä virheitä olevat palvelimet tulisi palauttaa 414-tilakoodi. |
| 415 |
Pyyntömenetelmälle ja pyydetylle resurssille osoitetut entiteetit eivät ole palvelimelle tuettavissa formaateissa, joten pyyntö kiellettiin. |
| 416 |
Jos pyyntöön liittyy Range-pyyntöotsikko, ja Range-otsikossa määritetty data-alue ei ole niiden käytettävissä olevien alueiden kanssa päällekäin, ja pyyntöön ei ole määritetty If-Range-otsikkoa, palvelimen on palautettava 416-tilakoodi. Jos vapaa-alue käytetään tavuja, tämä tarkoittaa, että pyynnön alueen ensimäisetä bytes-yhteensopivuudet ylittävät nykyisen resursseissa. Palvelimen pitäisi myös palauttaa 416-tilakoodin yhteydessä Content-Range-otsikko, joka kertoo nykyisen resurssin pituudesta. Tämän vastauksen ei myöskään voida käyttää multipart/byteranges Content-Typena. |
| 417 |
Pyyntöotsikossa Expect-otsikon määrittämä sisältö ei ole mahdollista palvelimelle hyväksyä, tai tämä palvelin on ylivetotehtävä, jolla on merkittäviä todisteita, että erityisratkaisu seuraavalla reitillä ei ole mahdollista. |
| 421 |
Asiakkaan IP-osoitteen ja palvelimen välinen yhteyksien määrä ylittää rajoitusten maksimimäärää. Yleensä tässä IP-osoitteessa tarkoitetaan asiakassa näkyvää osoitetta (esimerkiksi käyttäjän reititin tai välikäytin). Tässä yhteydessä yhteyslaskenta voi sisältää useampaa kuin yhtä loppukäyttäjää. |
| 422 |
Asiakkaan IP-osoitteen ja palvelimen välinen yhteyksien määrä ylittää rajoitusten maksimimäärää. Yleensä tässä IP-osoitteessa tarkoitetaan asiakassa näkyvää osoitetta (esimerkiksi käyttäjän reititin tai välikäytin). Tässä yhteydessä yhteyslaskenta voi sisältää useampaa kuin yhtä loppukäyttäjää. |
| 422 |
Pyyntö muoto on oikein, mutta semanttisista virheistä johtuen ei voida vastata. (RFC 4918 WebDAV) 423 Lukittu nykyinen resurssi on lukittu. (RFC 4918 WebDAV) |
| 424 |
Edellisestä pyynnöstä johtuva virhe aiheutti nykyisen pyynnön epäonnistumisen, kuten PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Määritellään WebDav -paremmissa kokoelmissa, mutta ei ole esiintynyt WebDAV-suotuisissa painotustavoissa (RFC 3658). |
| 426 |
Asiakkaan tulisi siirtyä TLS/1.0:aan. (RFC 2817) |
| 449 |
Microsoftin laajennettu, joka merkitsee, että pyyntö aiotaan uusittaa asianmukaisen toiminnan suorittamisen jälkeen. |
| 500 |
Palvelin kohtasi odottamattoman tilanteen, mikä aiheutti sen kykenemättömyyden käsitellä pyyntöä. Yleensä tämä ongelma ilmenee, kun palvelimen ohjelmakoodissa on virhe. |
| 501 |
Palvelin ei tue nykyisen pyynnön vaatimuksia. Kun palvelin ei tunnista pyynnön menetelmää eikä voi tuottaa tulleita pyynnön käsittelemistä. |
| 502 |
Palvelin, joka toimii väylillä tai välityspalvelimena, kohtasi virheliikenteen palautettua pyyntöä, johon se ei saanut kelvollista vastausta ylöspäin. |
| 503 |
Palvelin ei tällä hetkellä kykene käsittelemään pyyntöä, yleensä johtuen tilapäisestä kunnossapidosta tai ylikuormituksesta. Tämä on ajallinen olosuhde ja se palautetaan tietyn ajan kuluttua. Jos mahdollista, vastauksessa voisi olla Retry-After-otsikko, joka kertoo asiakkaalle, kuinka kauan he voivat yrittää uudelleen. Jos tätä Retry-After-tietoa ei anneta, asiakas voi käsitellä sen 500-vastauksen mukaan. Huomaa: 503-tilakoodin olemassaolo ei tarkoita, että palvelin pakko käyttää sitä ylikuormituksessa. Jotkut palvelimet vain toivovat, että ne kieltäytyvät asiakkaiden yhteyksistä. |
| 504 |
Palvelin, joka toimii väylillä tai välityspalvelimena, ei saa aikaa vastaanottaa pyyntöä ylöspäin (URI-merkitys; esimerkiksi HTTP, FTP, LDAP) tai alilähettävästä palvelimesta (esimerkiksi DNS). Huomaa: jotkut välikäytimmät palauttavat 400 -tai 500-virheitä DNS-kyselyn aikakatkaistessa. |
| 505 |
Palvelin ei tue tai kieltäytyy tukemasta HTTP-version käyttöä pääpyynnössä. Tämä tarkoittaa, että palvelin ei voi tai ei halua käyttää samaa versiota asiakkaan kanssa. Vastausotsikon on oltava kuvatta, miksi versioajobalanssia ei tehdä ja mitä protokollia palvelin tukee. |
| 506 |
Laajennettu “läpinäkyvien ympäristöjen neuvottelujärjestelmät” (RFC 2295), että palvelimella on sisäinen konfigurointi virhe. Pyydetyt neuvottelijalle resurssiset resurssit on määritelty käyttämään itseään, joten se ei ole käyttökelpoinen neuvottelussa. |
| 507 |
Palvelin ei voi tallentaa pyyntöyn vaadittuja sisältöjä. Tämä tilanne on ajallinen. |
| 509 |
Palvelin on saavuttanut kaistanleveysrajaan. Tämä ei ole virallinen tilakoodi, mutta se kuitenkin laajasti käytetään. |
| 510 |
Saadaksesi resurssit tarvitsemat käytännöt eivät ole täyttyneet. (RFC 2774) |