| Http-tilakoodi | Tilakoodi Merkitys |
|---|
| 100 | Asiakkaan tulisi jatkaa pyyntöjen lähettämistä. Tätä väliaikaista vastausta käytetään ilmoittamaan asiakkaalle, että palvelin on vastaanottanut osan sen pyynnöstä eikä sitä ole hylätty. Asiakkaan tulisi jatkaa pyynnön lopun lähettämistä tai jättää tämä vastaus huomiotta, jos pyyntö on valmis. Palvelimen on lähetettävä lopullinen vastaus asiakkaalle, kun pyyntö on valmis. |
| 101 | Palvelin on ymmärtänyt asiakkaan pyynnön ja ilmoittaa asiakkaalle Upgrade-viestiotsikon kautta, että hänen on käytettävä toista protokollaa pyynnön loppuunsaattamiseksi. Lähetettyään tämän vastauksen viimeisen tyhjän rivin palvelin siirtyy käyttämään Upgrade-viestiotsikossa määriteltyjä protokollia. Näin tulisi tehdä vain, jos uuteen protokollaan siirtyminen on edullisempaa. Esimerkiksi HTTP:n uuteen versioon siirtyminen on edullisempaa kuin vanhempaan versioon siirtyminen tai reaaliaikaiseen ja synkroniseen protokollaan siirtyminen, jotta voidaan toimittaa resursseja, jotka hyödyntävät tällaisia ominaisuuksia. |
| 102 | WebDAV:n (RFC 2518) laajentamat tilakoodit ilmaisevat, että käsittelyä jatketaan. |
| 200 | Pyyntö on onnistunut, ja vastauksen mukana palautetaan pyynnön haluama vastausotsikko tai tietorunko. |
| 201 | Pyyntö on täytetty ja uusi resurssi on luotu pyynnön vaatimalla tavalla ja sen URI on palautettu Location-otsikon kanssa. Jos vaadittua resurssia ei voida luoda ajoissa, palautetaan "202 Accepted". |
| 202 | Palvelin on hyväksynyt pyynnön, mutta ei ole vielä käsitellyt sitä. Aivan kuten se voidaan hylätä, pyyntöä voidaan lopulta toteuttaa tai olla toteuttamatta. Asynkronisten operaatioiden yhteydessä ei ole mitään kätevämpää kuin tämän tilakoodin lähettäminen. Vastauksen palauttamisen tilakoodilla 202 tarkoituksena on antaa palvelimelle mahdollisuus hyväksyä pyyntöjä muista prosesseista (kuten eräkohtainen operaatio, joka suoritetaan vain kerran päivässä) ilman, että asiakkaan on pidettävä yhteyttä palvelimeen, kunnes eräkohtainen operaatio on täysin valmis. Vastauksen, joka hyväksyy käsittelypyynnön ja palauttaa tilakoodin 202, PITÄÄ sisältää palautetussa kokonaisuudessa joitakin tietoja, jotka osoittavat prosessin nykyisen tilan, sekä osoitin käsittelyn tilanvalvontaan tai tilan ennusteeseen, jotta käyttäjä voi arvioida, onko operaatio suoritettu loppuun. |
| 203 | Palvelin on käsitellyt pyynnön onnistuneesti, mutta palautettu olio-otsikon metatieto ei ole alkuperäisellä palvelimella voimassa oleva lopullinen joukko, vaan paikallisen tai kolmannen osapuolen kopio. Nykyiset tiedot voivat olla alkuperäisen version osajoukko tai superset. Esimerkiksi resursseja sisältävä metatieto voi aiheuttaa sen, että alkuperäinen palvelin tietää metatiedon supertietoa. Tämän tilakoodin käyttö ei ole pakollista, ja se on tarkoituksenmukaista vain, jos vastaus olisi palauttanut 200 OK ilman sitä. |
| 204 | Palvelin käsitteli pyynnön onnistuneesti, mutta sen ei tarvitse palauttaa mitään fyysistä sisältöä, vaan se haluaa palauttaa päivitetyt metatiedot. Vastaus voi palauttaa uusia tai päivitettyjä metatietoja entiteettien otsikoiden muodossa. Jos tällaisia otsikoita on olemassa, niiden pitäisi vastata pyydettyjä muuttujia. Jos asiakas on selain, käyttäjän selaimen PITÄÄ säilyttää sivu, jolla pyyntö lähetettiin, ilman että asiakirjanäkymää muutetaan, vaikka eritelmän mukaan uutta tai päivitettyä metatietoa PITÄÄ soveltaa käyttäjän selaimen aktiivisessa näkymässä olevaan asiakirjaan. Koska 204-vastaus ei saa sisältää mitään viestirunkoa, se päättyy aina ensimmäiseen tyhjään riviin viestiotsikon jälkeen. |
| 205 | Palvelin käsitteli pyynnön onnistuneesti eikä palauttanut mitään. Toisin kuin 204-vastauksessa, tämän tilakoodin palauttavassa vastauksessa pyynnön esittäjää pyydetään kuitenkin palauttamaan asiakirjanäkymä. Tätä vastausta käytetään ensisijaisesti lomakkeen nollaamiseen heti käyttäjän syötteen hyväksymisen jälkeen, jotta käyttäjä voi helposti aloittaa uuden syötteen. Kuten 204-vastaus, tämäkin vastaus ei saa sisältää mitään viestirunkoa, ja se päättyy ensimmäiseen tyhjään riviin viestin otsikon jälkeen. |
| 206 | Palvelin on onnistuneesti käsitellyt osan GET-pyynnöstä. HTTP-lataustyökalut, kuten FlashGet tai Thunderbolt, käyttävät tämäntyyppistä vastausta suorittaakseen ajoittaisia latauksia tai jakaakseen suuren asiakirjan useisiin lataussegmentteihin samanaikaisesti. Pyynnön on sisällettävä Range-otsake, joka ilmaisee sisällön alueen, jonka asiakas haluaa vastaanottaa, ja se voi sisältää If-Range-ehdon pyyntöehtona. Vastauksen on sisällettävä seuraavat otsikkokentät: Content-Range, joka ilmaisee vastauksessa palautettavan sisällön laajuuden; jos kyseessä on usean segmentin lataus, jonka Content-Type on multipart/byteranges, jokaisen moniosaisen segmentin on sisällettävä Content-Range-kenttä, joka ilmaisee kyseisen segmentin sisällön laajuuden. Jos vastaus sisältää Content-Length-kentän, sen arvon on vastattava palauttamansa sisältöalueen todellista tavujen määrää. date ETag ja/tai Content-Location, jos saman pyynnön olisi pitänyt palauttaa 200-vastaus. Expires, Cache-Control ja/tai Vary, jos niiden arvot voivat poiketa muista vastauksista, joissa on samat muuttujat. Expires, Cache-Control ja/tai Vary, jos niiden arvot voivat poiketa muiden aiempien vastausten arvoista samojen muuttujien osalta. Tämän vastauksen EI SAA sisältää muita entiteetti-otsakkeita, jos pyyntö käyttää vahvaa If-Range-välimuistitietojen validointia, eikä SAA sisältää muita entiteetti-otsakkeita, jos pyyntö käyttää heikkoa If-Range-välimuistitietojen validointia; näin vältetään epäjohdonmukaisuudet välimuistiin tallennetun entiteettisisällön ja päivitettyjen entiteetti-otsakkeiden tietojen välillä. Muussa tapauksessa tämän vastauksen PITÄÄ sisältää kaikki ne entiteetti-otsikkokentät, jotka olisi pitänyt palauttaa kaikissa 200-vastauksissa, jotka olisi pitänyt palauttaa. Jos ETag- tai Last-Modified-otsikot eivät täsmälleen täsmää, asiakaspuolen välimuistin PITÄÄ estää vastauksessa 206 palautetun sisällön yhdistäminen aiemmin välimuistiin tallennettuun sisältöön. Kaikki välimuistit, jotka eivät tue Range- ja Content-Range-otsakkeita, eivät saa tallentaa välimuistiin vastauksen 206 palauttamaa sisältöä. |
| 207 | WebDAV:n (RFC 2518) laajentama tilakoodi tarkoittaa, että seuraava viestirunko on XML-viesti ja se voi sisältää sarjan erillisiä vastauskoodeja aiempien alakyselyjen määrästä riippuen. |
| 300 | Pyydetyllä resurssilla on sarja vaihtoehtoisia paluuviestejä, joista jokaisella on oma erityinen osoitteensa ja selainpohjaiset neuvottelutiedot. Käyttäjä tai selain voi itse valita haluamansa osoitteen uudelleenohjausta varten. Ellei kyseessä ole HEAD-pyyntö, vastauksen tulisi sisältää kokonaisuus, joka on luettelo resurssin ominaisuuksista ja osoitteista, joista käyttäjä tai selain voi valita sopivimman uudelleenohjausosoitteen. Tämän kokonaisuuden muoto määräytyy Content-Type-määrityksen muodon mukaan. Selain voi tehdä automaattisesti sopivimman valinnan vastauksen muodon ja selaimen omien kykyjen perusteella. RFC 2616 -määrittelyssä ei tietenkään määritellä, miten tällainen automaattinen valinta pitäisi tehdä. Jos palvelimella itsellään on jo vastausvaihtoehto, tämän vastauksen URI olisi määriteltävä kohdassa Location; selain voi käyttää tätä Location-arvoa osoitteena automaattista uudelleenohjausta varten. Lisäksi tämä vastaus on myös välimuistissa, ellei toisin määritetä. |
| 301 | Pyydetty resurssi on siirretty pysyvästi uuteen sijaintiin, ja kaikkien tulevien viittausten siihen tulisi käyttää jotakin tässä vastauksessa palautetuista URI-arvoista. Jos mahdollista, asiakkaiden, joilla on linkkien muokkausominaisuudet, tulisi muuttaa pyydetty osoite automaattisesti palvelimen palauttamaan osoitteeseen. Tämä vastaus on myös välimuistissa, ellei toisin mainita. Uusi pysyvä URI olisi palautettava vastauksen Location-kentässä. Ellei kyseessä ole HEAD-pyyntö, vastausyksikön tulisi sisältää hyperlinkki uuteen URI:hen ja lyhyt kuvaus. Jos kyseessä ei ole GET- tai HEAD-pyyntö, selain ei saa automaattisesti ohjata uudelleen, ellei käyttäjä ole vahvistanut sitä, koska pyynnön ehdot voivat muuttua tämän seurauksena. Huomautus: Kun jotkut HTTP/1.0-protokollaa käyttävät selaimet lähettävät POST-pyynnön ja saavat 301-vastauksen, seuraava uudelleenohjauspyyntö on GET. |
| 302 | Pyydetty resurssi vastaa nyt väliaikaisesti pyyntöön eri URI:ltä. Koska tämä uudelleenohjaus on tilapäinen, asiakkaan tulisi jatkossakin lähettää tulevat pyynnöt alkuperäiseen osoitteeseen. Tämä vastaus voidaan tallentaa välimuistiin vain, jos se on määritetty Cache-Control- tai Expires-kohdassa. Uusi väliaikainen URI tulisi palauttaa vastauksen Location-kentässä. Ellei kyseessä ole HEAD-pyyntö, vastausyksikön tulisi sisältää hyperlinkki uuteen URI:hen ja lyhyt kuvaus. Jos kyseessä ei ole GET- tai HEAD-pyyntö, selain ei saa automaattisesti ohjata uudelleen, ellei käyttäjä ole vahvistanut sitä, koska pyynnön ehdot voivat muuttua tämän seurauksena. Huomautus: Vaikka RFC 1945- ja RFC 2068-määrittelyt eivät salli asiakkaan muuttaa pyynnön menetelmää uudelleenohjauksen yhteydessä, monet nykyiset selaimet käsittelevät 302-vastausta 303-vastauksena ja käyttävät GET-vastausta sijainnissa määritettyyn URI:hen pääsemiseksi välittämättä alkuperäisen pyynnön menetelmästä. Tilakoodit 303 ja 307 on lisätty selventämään, mitä vastausta palvelin odottaa asiakkaalta. |
| 303 | Vastaus nykyiseen pyyntöön löytyy toisesta URI:stä, ja asiakkaan tulisi käyttää kyseistä resurssia GET-menetelmällä. Tämä menetelmä on olemassa ensisijaisesti siksi, että skriptin aktivoima POST-pyynnön tuloste voidaan ohjata uuteen resurssiin. Tämä uusi URI ei ole vaihtoehtoinen viittaus alkuperäiseen resurssiin. Lisäksi 303-vastausta ei saa tallentaa välimuistiin. Toinen pyyntö (uudelleenohjaus) voidaan tietenkin tallentaa välimuistiin. Uusi URI olisi palautettava vastauksen Location-kentässä. Ellei kyseessä ole HEAD-pyyntö, vastausyksikön tulisi sisältää hyperlinkki uuteen URI:hen ja lyhyt kuvaus. Huomautus: Monet HTTP/1.1-versiota aikaisemmat selaimet eivät ymmärrä kunnolla 303-tilaa. Jos vuorovaikutus näiden selainten kanssa on otettava huomioon, 302-tilakoodin pitäisi riittää, koska useimmat selaimet käsittelevät 302-vastausta täsmälleen samalla tavalla kuin edellä mainittu määrittely vaatii asiakasta käsittelemään 303-vastausta. |
| 304 | Palvelimen PITÄÄ palauttaa tämä tilakoodi, jos asiakas lähettää ehdollisen GET-pyynnön, joka on sallittu, eikä asiakirjan sisältö (joko edellisen käynnin jälkeen tai pyynnön ehtojen mukaisesti) ole muuttunut. 304-vastaukset eivät saa sisältää viestirunkoja, ja siksi ne päättyvät aina ensimmäiseen tyhjään riviin viestiotsikon jälkeen. Vastauksen PITÄÄ sisältää seuraavat otsikot: Päivämäärä, paitsi jos palvelimella ei ole kelloa. Jos palvelin, jolla ei ole kelloa, noudattaa näitä sääntöjä, välityspalvelin ja asiakas voivat itse lisätä Date-kentän saapuvan vastauksen otsikkoon (kuten RFC 2068:ssa on määritelty), ja välimuistitallennusmekanismi toimii oikein.ETag ja/tai Content-Location, jos sama pyyntö olisi palauttanut 200-vastauksen.Expires. Expires, Cache-Control ja/tai Vary, jos arvo voi poiketa saman muuttujan muiden aiempien vastausten vastaavasta arvosta. Jos tämä vastauspyyntö käyttää vahvaa välimuistin validointia, tämän vastauksen ei pitäisi sisältää muita olio-otsakkeita; muussa tapauksessa (esim. ehdollinen GET-pyyntö käyttää heikkoa välimuistin validointia) tämä vastaus ei saa sisältää muita olio-otsakkeita; näin vältetään epäjohdonmukaisuudet välimuistiin tallennetun oliosisällön ja päivitettyjen olio-otsakkeiden tietojen välillä. Jos 304-vastaus osoittaa, että oliota ei ole tällä hetkellä välimuistissa, välimuistijärjestelmän on jätettävä vastaus huomiotta ja toistettava pyyntö ilman rajoitusta. Jos vastaanotetaan 304-vastaus, jossa pyydetään välimuistiin tallennetun tietueen päivittämistä, välimuistijärjestelmän on päivitettävä koko tietue vastauksessa päivitettyjen kenttien arvojen mukaiseksi. |
| 305 | Pyydettyä resurssia on käytettävä määritellyn välityspalvelimen kautta. location-kenttä antaa tiedon URI:stä, jossa määritetty välityspalvelin sijaitsee. vastaanottajan on lähetettävä erillinen pyyntö toistuvasti päästäkseen resurssiin tämän välityspalvelimen kautta. Vain alkuperäinen palvelin voi luoda 305-vastauksen. Huomautus: RFC 2068:sta ei käy selvästi ilmi, että 305-vastaus on tarkoitettu yksittäisen pyynnön uudelleenohjaamiseen ja että vain alkuperäinen palvelin voi rakentaa sen. Näiden rajoitusten huomiotta jättäminen voi johtaa vakaviin turvallisuusseurauksiin. |
| 306 | Määrittelyn uusimmassa versiossa tilakoodia 306 ei enää käytetä. |
| 307 | Pyydetty resurssi vastaa nyt väliaikaisesti pyyntöön eri URI:ltä. Koska tällaiset uudelleenohjaukset ovat tilapäisiä, asiakkaiden tulisi jatkossakin lähettää pyynnöt alkuperäiseen osoitteeseen. Tämä vastaus voidaan tallentaa välimuistiin vain, jos se on määritetty Cache-Control- tai Expires-kohdassa. Uusi väliaikainen URI tulisi palauttaa vastauksen Location-kentässä. Ellei kyseessä ole HEAD-pyyntö, vastausyksikön tulisi sisältää hyperlinkki uuteen URI:hen ja lyhyt kuvaus. Koska jotkin selaimet eivät tunnista vastausta 307, edellä mainitut tiedot on lisättävä, jotta käyttäjä voi ymmärtää ja pyytää pääsyä uuteen URI:hen. Jos kyseessä ei ole GET- tai HEAD-pyyntö, selain estää automaattisen uudelleenohjauksen, ellei käyttäjä vahvista sitä, koska pyynnön ehdot voivat muuttua. |
| 400 | 1. On tapahtunut semanttinen virhe, eikä palvelin voi ymmärtää nykyistä pyyntöä. Ellei sitä ole muutettu, asiakkaan ei pitäisi lähettää tätä pyyntöä toistuvasti. 2. Pyynnön parametrit ovat vääriä. |
| 401 | Nykyinen pyyntö edellyttää käyttäjän todennusta. Vastauksen on sisällettävä WWW-Authenticate-otsake pyydetylle resurssille käyttäjätietojen kysymiseksi. Asiakas voi lähettää toistuvasti pyynnön, joka sisältää asianmukaiset Authorisation-otsikkotiedot. Jos nykyinen pyyntö sisältää jo Authorisation-tunnistetiedot, 401-vastaus tarkoittaa, että palvelin tarkistaa, että nämä tunnisteet on hylätty. Jos 401-vastaus sisältää saman todennuskyselyn kuin edellinen vastaus ja selain on jo yrittänyt todennusta vähintään kerran, selaimen PITÄÄ esittää käyttäjälle vastauksen sisältämät entiteettitiedot, koska nämä entiteettitiedot voivat sisältää asiaankuuluvaa diagnoositietoa. Katso RFC 2617. |
| 402 | Tämä tilakoodi on varattu mahdollisia tulevia vaatimuksia varten. |
| 403 | Palvelin on ymmärtänyt pyynnön, mutta kieltäytyy suorittamasta sitä. Toisin kuin 401-vastauksessa, todennus ei tarjoa apua, eikä tätä pyyntöä pidä lähettää uudelleen. Jos kyseessä ei ole HEAD-pyyntö ja palvelin haluaa pystyä kertomaan selkeästi, miksi pyyntöä ei voida suorittaa, kieltäytymisen syy olisi kuvattava kokonaisuudessa. Palvelin voi tietenkin myös palauttaa 404-vastauksen, jos se ei halua antaa asiakkaalle mitään tietoja. |
| 404 | Pyyntö epäonnistui, pyydettyä resurssia ei löytynyt palvelimelta. Käyttäjälle ei anneta tietoa siitä, onko tilanne väliaikainen vai pysyvä. Jos palvelin on tietoinen tilanteesta, sen tulisi käyttää tilakoodia 410 kertoakseen käyttäjälle, että vanha resurssi ei ole pysyvästi käytettävissä jonkin sisäisen konfigurointimekanismin vuoksi ja että uudelleenohjausta ei ole saatavilla. 404:ää käytetään yleisesti silloin, kun palvelin ei halua paljastaa, miksi pyyntö hylättiin tai kun muuta sopivaa vastausta ei ole saatavilla. |
| 405 | Pyyntörivillä määritettyä pyyntömenetelmää ei voida käyttää vastaavan resurssin pyytämiseen. Vastauksen on palautettava Allow-otsake, jossa ilmoitetaan luettelo pyyntömenetelmistä, jotka ovat hyväksyttäviä kyseiselle resurssille. Koska PUT- ja DELETE-menetelmät kirjoittavat palvelimella olevaan resurssiin, useimmat verkkopalvelimet eivät tue näitä pyyntömenetelmiä tai eivät salli niitä oletusarvoisesti, ja ne palauttavat 405-virheilmoituksen tällaisista pyynnöistä. |
| 406 | Pyydetyn resurssin sisältöominaisuudet eivät täytä pyyntöotsikon ehtoja, eikä vastausoliota voida luoda. Ellei kyseessä ole HEAD-pyyntö, vastauksen pitäisi palauttaa kokonaisuus, joka sisältää luettelon kokonaisuuksien ominaisuuksista ja osoitteista, joista käyttäjä tai selain voi valita sopivimman. Entiteetin muoto määräytyy Content-Type-otsakkeessa määritellyn mediatyypin mukaan. Selaimet voivat tehdä omat parhaat valintansa muodon ja omien kykyjensä perusteella. Määritelmässä ei kuitenkaan määritellä mitään kriteerejä tällaisten automaattisten valintojen tekemiseksi. |
| 407 | Samanlainen kuin 401-vastaus, paitsi että asiakkaan on todennettava välityspalvelimella. Välityspalvelimen PITÄÄ palauttaa Proxy-Authenticate identiteetin kyselyä varten. Asiakas VOI palauttaa Proxy-Authorization-otsikon todennusta varten. Katso RFC 2617. |
| 408 | Pyynnön aikakatkaisu. Asiakas ei saanut pyynnön lähettämistä valmiiksi siinä ajassa, jonka palvelin oli valmis odottamaan. Asiakas voi lähettää pyynnön milloin tahansa uudelleen tekemättä muutoksia. |
| 409 | Pyyntöä ei voitu suorittaa loppuun pyydetyn resurssin nykyisen tilan kanssa ilmenneen ristiriidan vuoksi. Tätä koodia saa käyttää vain, jos käyttäjän katsotaan pystyvän ratkaisemaan ristiriidan ja lähettämään uuden pyynnön uudelleen. Vastauksen tulisi sisältää riittävästi tietoa, jotta käyttäjä voi selvittää ristiriidan syyn. Ristiriitoja esiintyy yleensä PUT-pyyntöjen käsittelyssä. Jos esimerkiksi versiotarkistusympäristössä tietyn resurssin muuttamiseksi lähetettyyn PUT-pyyntöön liitetyt versiotiedot ovat ristiriidassa edellisen (kolmannen osapuolen) pyynnön kanssa, palvelimen pitäisi palauttaa 409-virheilmoitus, jossa käyttäjälle ilmoitetaan, että pyyntöä ei voitu suorittaa loppuun. Tässä tapauksessa vastausyksikkö sisältää todennäköisesti vertailun kahden ristiriitaisen version välisistä eroista, jotta käyttäjä voi lähettää uuden version uudelleen yhdistämisen jälkeen. |
| 410 | Pyydetty resurssi ei ole enää saatavilla palvelimella eikä sillä ole tunnettua välitysosoitetta. Tällaista tilaa olisi pidettävä pysyvänä. Jos mahdollista, asiakkaiden, joilla on linkkien muokkausominaisuudet, tulisi poistaa kaikki viittaukset tähän osoitteeseen käyttäjän luvalla. Jos palvelin ei tiedä tai voi määrittää, onko tämä tila pysyvä, olisi käytettävä tilakoodia 404. Ellei toisin mainita, tämä vastaus on välimuistissa.410 Vastauksen tarkoituksena on ensisijaisesti auttaa webmasteria sivuston ylläpidossa ilmoittamalla käyttäjälle, että resurssi ei ole enää käytettävissä ja että palvelimen omistaja haluaa, että kaikki etäyhteydet tähän resurssiin poistetaan. Tämäntyyppinen tapahtuma on yleinen ajallisesti rajoitetuissa lisäarvopalveluissa. Vastaavasti 410-vastausta käytetään ilmoittamaan asiakkaille, että resurssi, joka alun perin kuului jollekin yksittäiselle henkilölle nykyisellä palvelinsivustolla, ei ole enää käytettävissä. Palvelimen omistaja päättää tietenkin itse, onko kaikki pysyvästi saavuttamattomat resurssit merkittävä 410-merkinnällä ja kuinka kauan merkintää on säilytettävä. |
| 411 | Palvelin kieltäytyy hyväksymästä pyyntöjä, joissa ei ole määritelty Content-Length-otsikkoa. Kun asiakas on lisännyt kelvollisen Content-Length-otsikon, joka osoittaa pyynnön viestirungon pituuden, hän voi lähettää pyynnön uudelleen. |
| 412 | Palvelin ei täyttänyt yhtä tai useampaa edellytystä, kun se tarkisti, että ne oli annettu pyynnön otsikkokentässä. Tämän tilakoodin avulla asiakas voi asettaa esiehdot pyynnön metaviestissä (pyynnön otsikkokentän tiedot) resurssia hankkiessaan, jolloin estetään pyyntömenetelmän soveltaminen muuhun kuin haluttuun sisältöön. |
| 413 | Palvelin kieltäytyy käsittelemästä tämänhetkistä pyyntöä, koska se lähettää kokonaisuustietoja, jotka ovat kooltaan suurempia kuin palvelin haluaa tai pystyy käsittelemään. Tässä tapauksessa palvelin voi sulkea yhteyden estääkseen asiakasta jatkamasta tämän pyynnön lähettämistä. Jos tämä ehto on tilapäinen, palvelimen pitäisi palauttaa Retry-After-vastausotsikko, joka ilmoittaa asiakkaalle, kuinka pitkän ajan kuluttua se voi yrittää uudelleen. |
| 414 | Pyynnön URI:n pituus ylittää palvelimen tulkitseman pituuden, joten palvelin kieltäytyy palvelemasta pyyntöä. Tämä on harvinaista, ja se tapahtuu usein silloin, kun lomakkeen lähettäminen, jossa olisi pitänyt käyttää POST-menetelmää, muuttuu GET-menetelmäksi, jolloin Query String on pitkä. Uudelleenohjauksen URI:n "mustat aukot", kuten vanhan URI:n käyttäminen osana uutta URI:tä jokaisen uudelleenohjauksen yhteydessä, jolloin URI on pitkä useiden uudelleenohjausten jälkeen. Asiakkaat yrittävät hyökätä palvelimiin hyödyntämällä joissakin palvelimissa olevia tietoturva-aukkoja. Tällaiset palvelimet käyttävät kiinteän pituisia puskureita lukemaan tai käsittelemään pyynnön URI:tä, ja kun GET-käskyn jälkeiset parametrit ylittävät tietyn arvon, puskurin ylivuoto voi aiheuttaa puskurin ylivuodon, joka johtaa mielivaltaisen koodin suorittamiseen [1]. Palvelimien, joissa ei ole tällaisia haavoittuvuuksia, pitäisi palauttaa tilakoodi 414. |
| 415 | Tällä hetkellä pyydetyn menetelmän ja pyydetyn resurssin osalta pyynnössä esitetty olio ei ole palvelimen tukemassa muodossa, joten pyyntö hylätään. |
| 416 | Jos pyyntö sisältää Range-pyyntöotsikon, ja kaikki Range-otsikossa määritetyt data-alueet eivät ole päällekkäisiä nykyisen resurssin käytettävissä olevien alueiden kanssa, eikä If-Range-pyyntöotsikkoa ole määritelty pyynnössä, palvelimen pitäisi palauttaa tilakoodi 416. Jos Range käyttää tavualueita, näin on, jos kaikkien pyynnössä määritettyjen data-alueiden ensimmäinen tavuasema ylittää nykyisen resurssin pituuden. Palvelimen tulisi myös sisällyttää Content-Range-olio-otsake, joka määrittää nykyisen resurssin pituuden yhdessä tilakoodin 416 kanssa. Tässä vastauksessa ei myöskään saa käyttää multipart/byteranges-tyyppiä Content-Type-tyyppinä. |
| 417 | Palvelin ei voi täyttää pyynnön Expect-otsakkeessa määriteltyä odotettua sisältöä, tai tämä palvelin on välityspalvelin, jolla on selkeää näyttöä siitä, että Expectin sisältöä ei voida täyttää nykyisen reitin seuraavassa solmussa. |
| 421 | Yhteyksien määrä palvelimeen IP-osoitteesta, jossa nykyinen asiakas sijaitsee, ylittää palvelimen salliman enimmäismäärän. Yleensä IP-osoitteella tarkoitetaan tässä asiakkaan osoitetta palvelimelta katsottuna (esim. käyttäjän yhdyskäytävän tai välityspalvelimen osoite). Tässä tapauksessa yhteyden määrä voi koskea useampaa kuin yhtä loppukäyttäjää. |
| 422 | Nykyisen asiakkaan IP-osoitteesta palvelimelle tulevien yhteyksien määrä ylittää palvelimen salliman enimmäismäärän. Yleensä IP-osoite tarkoittaa tässä asiakkaan osoitetta palvelimelta katsottuna (esim. käyttäjän yhdyskäytävän tai välityspalvelimen osoite). Tässä tapauksessa yhteyden määrä voi koskea useampaa kuin yhtä loppukäyttäjää. |
| 422 | Pyyntö oli muotoiltu oikein, mutta siihen ei voitu vastata, koska se sisälsi semanttisia virheitä. (RFC 4918 WebDAV) 423 Lukittu Nykyinen resurssi on lukittu. (RFC 4918 WebDAV) |
| 424 | Nykyinen pyyntö epäonnistui edellisessä pyynnössä, kuten PROPPATCHissa, ilmenneen virheen vuoksi. (RFC 4918 WebDAV). |
| 425 | Määritelty WebDav Advanced Collections -luonnoksessa, mutta ei esiinny WebDAV Sequential Collections Protocol -protokollassa (RFC 3658). |
| 426 | Asiakkaiden tulisi siirtyä TLS/1.0:aan.(RFC 2817). |
| 449 | Microsoftin laajentama merkintä, jonka mukaan pyyntöjä olisi yritettävä uudelleen sen jälkeen, kun asianmukainen toimenpide on suoritettu. |
| 500 | Palvelin kohtasi odottamattoman olosuhteen, joka esti sitä suorittamasta pyynnön käsittelyä loppuun. Yleensä tämä ongelma ilmenee, kun palvelimen ohjelmakoodissa on virhe. |
| 501 | Palvelin ei tue tiettyä ominaisuutta, jota nykyinen pyyntö edellyttää. Kun palvelin ei tunnista pyydettyä menetelmää eikä pysty tukemaan sen pyyntöä minkään resurssin osalta. |
| 502 | Yhdyskäytävänä tai välityspalvelimena toimiva palvelin saa virheellisen vastauksen ylemmän tason palvelimelta, kun se yrittää suorittaa pyynnön. |
| 503 | Palvelin ei pysty tällä hetkellä käsittelemään pyyntöä palvelimen tilapäisen ylläpidon tai ylikuormituksen vuoksi. Tämä tila on väliaikainen ja palautuu jonkin ajan kuluttua. Jos odotettavissa on viivettä, vastaus voi sisältää Retry-After-otsakkeen, joka osoittaa viivettä. Jos tätä Retry-After-tietoa ei anneta, asiakkaan on käsiteltävä sitä samalla tavalla kuin 500-vastausta. Huomautus: Tilakoodin 503 olemassaolo ei tarkoita, että palvelimen on käytettävä sitä, jos se on ylikuormitettu. Jotkin palvelimet haluavat yksinkertaisesti kieltää asiakkaalta yhteyden. |
| 504 | Palvelin, joka toimii yhdyskäytävänä tai välityspalvelimena ja joka yrittää suorittaa pyynnön, ei saa ajoissa vastausta edeltävältä palvelimelta (URI:n avulla tunnistettu palvelin, kuten HTTP, FTP, LDAP) tai toissijaiselta palvelimelta (kuten DNS). Huomautus: Jotkin välityspalvelimet palauttavat 400- tai 500-virheen, kun DNS-haku päättyy. |
| 505 | Palvelin ei tue tai kieltäytyy tukemasta pyynnössä käytettyä HTTP-versiota. Tämä tarkoittaa, että palvelin ei pysty tai halua käyttää samaa versiota kuin asiakas. Vastauksen tulisi sisältää kokonaisuus, jossa kuvataan, miksi versiota ei tueta ja mitä protokollia palvelin tukee. |
| 506 | Laajennettu Transparent Content Negotiation Protocol -protokollassa (RFC 2295) kuvaamaan palvelimen sisäistä virheellistä konfiguraatiota: pyydetty Negotiation Variant -resurssi on konfiguroitu käyttämään itseään läpinäkyvässä sisältöneuvottelussa, eikä se näin ollen ole sopiva kohde neuvotteluprosessissa. |
| 507 | Palvelin ei pysty tallentamaan pyynnön täyttämiseen tarvittavaa sisältöä. Tätä tilaa pidetään tilapäisenä.WebDAV (RFC 4918). |
| 509 | Palvelimen kaistanleveysraja on saavutettu. Tämä ei ole virallinen tilakoodi, mutta sitä käytetään silti yleisesti. |
| 510 | Resurssin hankkimiseen vaadittavaa käytäntöä ei jäänyt täyttämättä. (RFC 2774) |