Verkkotyökalut
Http-tilakoodit Tilakoodin 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 loppuosan 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-otsikon kautta, että pyynnön loppuunsaattamiseen on käytetty eri protokollaa. Lähetettyään vastauksen viimeisen tyhjän rivin palvelin siirtyy Upgrade-otsakkeessa määriteltyihin protokolliin. Näin tulisi tehdä vain, jos uuteen protokollaan siirtyminen on edullisempaa. Esimerkiksi HTTP:n uuteen versioon siirtyminen voi olla edullisempaa kuin vanhempaan versioon siirtyminen tai reaaliaikaiseen, synkroniseen protokollaan siirtyminen, jotta voidaan toimittaa resursseja, jotka hyödyntävät tällaisia ominaisuuksia.
102 WebDAV:n (RFC 2518) laajentamat tilakoodit osoittavat, että käsittelyä jatketaan.
200 Pyyntö onnistui, ja vastauksen mukana palautetaan vastauksen otsikot tai pyynnön haluama tietorunko.
201 Pyyntö on täytetty ja vastauksena pyyntöön on luotu uusi resurssi, jonka URI on palautettu Location-otsikon kanssa. Jos pyydettyä resurssia ei voida luoda ajoissa, palautetaan seuraava vastaus'202 Accepted'。
202 Palvelin on hyväksynyt pyynnön, mutta ei ole vielä käsitellyt sitä. Samoin kuin se voidaan hylätä, pyyntöä voidaan lopulta suorittaa tai olla suorittamatta. Asynkronisissa operaatioissa ei ole mitään kätevämpää kuin tämän tilakoodin lähettäminen. Vastauksen 202 palauttamisen 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 tarvitsee ylläpitää yhteyttä palvelimeen, kunnes eräkohtainen operaatio on valmis. Vastauksen, joka hyväksyy pyynnön käsittelyä varten ja palauttaa tilakoodin 202, tulisi sisältää palautetussa kokonaisuudessa tietoja prosessin tämänhetkisestä tilasta sekä osoitin käsittelyn tilanvalvontaan tai tilan ennusteeseen, jotta käyttäjä voi arvioida, onko operaatio suoritettu loppuun vai ei.
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 osajoukko tai superset. Esimerkiksi resursseja sisältävä metatieto voi aiheuttaa sen, että alkuperäispalvelin 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 olio-otsakkeiden muodossa. Jos nämä otsikot ovat 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 muutoksia asiakirjanäkymään, vaikka uusia tai päivitettyjä metatietoja PITÄISI määrittelyn mukaan 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äsittelee pyynnön onnistuneesti eikä palauta mitään. Toisin kuin vastaus 204, vastaus, joka palauttaa tämän tilakoodin, pyytää pyynnön esittäjää kuitenkin palauttamaan asiakirjanäkymän. 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 tiedoston useisiin latauksiin 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, tai, jos kyseessä on moniosainen lataus, jonka Content-Type on multipart/byteranges, Content-Range-kenttä jokaisessa moniosaisessa segmentissä, joka ilmaisee kyseisen segmentin sisällön laajuuden. Jos vastaus sisältää Content-Length-kentän, sen arvon on vastattava palautetun sisältöalueen todellista tavujen lukumäärää. Expires, Cache-Control ja/tai Vary, jos niiden arvot voivat poiketa muiden samoja muuttujia sisältävien aiempien vastausten arvoista. Tämän vastauksen ei pitäisi sisältää muita entiteetti-otsakkeita, jos pyyntö käyttää vahvaa If-Range-välimuistin validointia, eikä muita entiteetti-otsakkeita, jos pyyntö käyttää heikkoa If-Range-välimuistin validointia; näin vältetään epäjohdonmukaisuudet välimuistiin tallennetun entiteetin sisällön ja päivitettyjen entiteetti-otsakkeiden tietojen välillä. Muussa tapauksessa tämän vastauksen PITÄÄ sisältää kaikki ne olio-otsikkokentät, jotka olisi pitänyt palauttaa 200-vastauksessa. Jos ETag- tai Last-Modified-otsikot eivät täsmälleen täsmää, asiakkaan välimuistin ei pitäisi sallia vastauksessa 206 palautetun sisällön yhdistämistä 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 laajentamat tilakoodit(RFC 2518) WebDAV:n 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 vastauksia, joilla kullakin on oma erityinen osoitteensa ja selainpohjaiset neuvottelutiedot. Käyttäjän tai selaimen tehtävänä on valita haluamansa osoite 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ämä automaattinen valinta pitäisi tehdä. Jos palvelimella itsellään on jo ensisijainen vastausvaihtoehto, palautuksen URI olisi määriteltävä kohdassa Location; selaimet voivat käyttää tätä Location-arvoa osoitteena automaattista uudelleenohjausta varten. Lisäksi vastaus on 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:ista. 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ää pyynnöt alkuperäiseen osoitteeseen. Vastaus voidaan tallentaa välimuistiin vain, jos se on määritetty Cache-Control- tai Expires-kohdassa. Uusi väliaikainen 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: Vaikka RFC 1945- ja RFC 2068-määritykset eivät salli asiakkaan muuttaa pyynnön menetelmää uudelleenohjauksen aikana, 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 korvaava viittaus alkuperäiseen resurssiin. Myöskään 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:tä edeltävät selaimet eivät ymmärrä kunnolla 303-tilaa. Jos vuorovaikutus näiden selainten kanssa on otettava huomioon, 302-tilakoodin pitäisi toimia, koska useimmat selaimet käsittelevät 302-vastausta täsmälleen samalla tavalla kuin yllä oleva määrittely vaatii asiakasta käsittelemään 303-vastausta.
304 Palvelimen pitäisi palauttaa tämä tilakoodi, jos asiakas lähettää ehdollisen GET-pyynnön ja pyyntö on sallittu, eikä asiakirjan sisältö ole muuttunut (joko edellisen käynnin jälkeen tai pyynnön ehtojen mukaisesti). 304-vastaukset eivät saa sisältää viestirunkoa, ja siksi ne päättyvät aina ensimmäiseen tyhjään riviin viestin otsikon jälkeen. Vastauksen on sisällettävä seuraavat otsikkotiedot: Päivämäärä, ellei palvelimella 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 (RFC 2068:n mukaisesti), ja välimuistimekanismi toimii oikein. 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 muiden samoja muuttujia sisältävien aiempien vastausten arvoista. Jos vastauspyyntö käyttää vahvaa välimuistin validointia, vastauksen ei pitäisi sisältää ylimääräisiä olio-otsakkeita; muussa tapauksessa (esim. ehdollinen GET-pyyntö käyttää heikkoa välimuistin validointia) vastaus ei saa sisältää ylimääräisiä 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 tietoa määritellyn välityspalvelimen URI:stä, ja 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ä sen voi luoda vain alkuperäinen palvelin. Näiden rajoitusten huomiotta jättäminen voi johtaa vakaviin turvallisuusseurauksiin.
306 Määrittelyn uusimmassa versiossa tilakoodia 306 ei enää käytetä.
307 Pyydetyt resurssit vastaavat nyt tilapäisesti eri URI:iden pyyntöihin. Koska tämä uudelleenohjaus on väliaikainen, 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 olisi palautettava 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, on tarpeen lisätä edellä mainitut tiedot, 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, semanttinen virhe, palvelin ei voi ymmärtää nykyistä pyyntöä. Ellei sitä ole muutettu, asiakkaan ei pitäisi toistaa pyyntöä. 2, pyynnön parametrit ovat väärät.
401 Nykyinen pyyntö edellyttää käyttäjän todennusta. Vastauksen on sisällettävä WWW-Authenticate-otsake pyydetylle resurssille, jossa kysytään käyttäjätietoja. Asiakas voi lähettää pyynnön uudelleen asianmukaisilla Authorisation-otsikkotiedoilla. Jos nykyinen pyyntö sisältää jo valtuutustiedot, 401-vastaus tarkoittaa, että palvelin tarkistaa, että nämä tiedot on hylätty. Jos 401-vastaus sisältää saman todennuskyselyn kuin edellinen vastaus ja selain on jo yrittänyt ainakin kerran todennusta, selaimen on näytettävä 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 auta, eikä pyyntöä pidä lähettää uudelleen. Jos kyseessä ei ole HEAD-pyyntö ja palvelin haluaa pystyä kertomaan, miksi pyyntöä ei voida suorittaa, kieltäytymisen syy olisi kuvattava kokonaisuudessa. Palvelin voi tietysti myös palauttaa 404-vastauksen, jos se ei halua, että asiakas saa mitään tietoa.
404 Pyyntö epäonnistui, pyydettyä resurssia ei löytynyt palvelimelta. Käyttäjälle ei ole tietoa siitä, onko tilanne väliaikainen vai pysyvä. Jos palvelin on tietoinen tilanteesta, sen tulisi käyttää tilakoodia 410 kertoakseen palvelimelle, 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 oletusarvoisesti tue tai salli niitä ja palauttavat 405-virheilmoituksen tällaisista pyynnöistä.
406 Pyydetyn resurssin sisältöominaisuudet eivät täytä pyynnön otsikon ehtoja, eikä vastausoliota voida luoda. Ellei kyseessä ole HEAD-pyyntö, vastauksen pitäisi palauttaa kokonaisuus, joka sisältää luettelon osoitteista, joista käyttäjä tai selain voi valita sopivimmat kokonaisuuden ominaisuudet. Entiteetin muoto määräytyy Content-Type-otsakkeessa määritellyn mediatyypin mukaan. Selain voi tehdä parhaan valinnan 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 itsensä välityspalvelimella. Välityspalvelimen PITÄÄ palauttaa Proxy-Authenticate identiteetin kyselyä varten. Asiakas voi palauttaa Proxy-Authorisation-otsikon todennusta varten. Katso RFC 2617.
408 Pyynnön aikakatkaisu. Asiakas ei saanut pyyntöä valmiiksi siinä ajassa, jonka palvelin oli valmis odottamaan. Asiakas voi lähettää pyynnön milloin tahansa uudelleen tekemättä mitään 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 usein PUT-pyyntöjen käsittelyssä. Esimerkiksi versiotarkistusympäristössä PUT-pyyntö, joka lähetetään tietyn resurssin muuttamiseksi versiotiedoilla, jotka ovat ristiriidassa aikaisemman (kolmannen osapuolen) pyynnön kanssa, 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 eroista, jotta käyttäjä voi lähettää uuden, yhdistetyn version uudelleen.
410 Pyydetty resurssi ei ole enää saatavilla palvelimella eikä välitysosoitetta tunneta. Tällaista tilannetta on 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 ei voi määrittää, onko tilanne pysyvä, tulisi käyttää 404-tilakoodia. Ellei toisin mainita, tämä vastaus on välimuistissa. 410-vastauksen tarkoituksena on ensisijaisesti auttaa webmasteria ylläpitämään sivustoa ilmoittamalla käyttäjälle, että resurssi ei ole enää käytettävissä ja että palvelimen omistaja haluaa, että myös kaikki etäyhteydet resurssiin poistetaan. Tämäntyyppinen tapahtuma on yleinen määräaikaisissa lisäarvopalveluissa. Vastaavasti 410-vastausta käytetään ilmoittamaan asiakkaalle, että tietylle henkilölle kuuluva resurssi ei ole enää käytettävissä nykyisellä palvelinsivustolla. Tietenkin on myös tärkeää, onko kaikki pysyvästi saavuttamattomat resurssit merkittävä sellaisiksi ja kuinka kauan niitä on pidettävä sellaisina.'410 Gone'， ja kuinka kauan sitä tulisi säilyttää, on täysin palvelimen omistajan päätettävissä.
411 Palvelin kieltäytyy hyväksymästä pyyntöjä, joissa ei ole määritelty Content-Length-otsikkoa. Asiakas voi lähettää pyynnön uudelleen lisättyään siihen kelvollisen Content-Length-otsikon, joka osoittaa pyynnön viestirungon pituuden.
412 Palvelin ei täyttänyt yhtä tai useampaa pyynnön otsikkokentässä annettua edellytystä pyyntöä validoidessaan. Tämän tilakoodin avulla asiakas voi asettaa esiehdot pyynnön metatietoihin (pyynnön otsikkokentän tietoihin) resurssia hankkiessaan, jolloin estetään pyyntömenetelmän soveltaminen muihin resursseihin kuin haluttuun sisältöön.
413 Palvelin kieltäytyy käsittelemästä nykyistä pyyntöä, koska siinä lähetetään enemmän fyysistä dataa kuin palvelin haluaa tai pystyy käsittelemään. Tässä tapauksessa palvelin voi sulkea yhteyden estääkseen asiakasta jatkamasta pyynnön lähettämistä. Jos tilanne on tilapäinen, palvelimen tulisi palauttaa Retry-After-otsikko, jolla se ilmoittaa asiakkaalle, kuinka paljon aikaa sillä on aikaa yrittää uudelleen.
414 Pyynnön URI on pidempi kuin palvelin pystyy tulkitsemaan, joten palvelin kieltäytyy palvelemasta pyyntöä. Tämä on harvinaista ja tapahtuu yleensä silloin, kun lomakkeen lähettäminen, jossa olisi pitänyt käyttää POST-menetelmää, muuttuu GET-menetelmäksi, jolloin kyselymerkkijono on pitkä. Uudelleenohjauksen URI:n "mustat aukot", kuten vanhan URI:n käyttäminen osana uutta URI:tä jokaisessa uudelleenohjauksessa, 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äpituista puskuria lukemaan tai käsittelemään pyydettyä URI:tä, mikä voi johtaa puskurin ylivuotoon, kun GET-parametri ylittää tietyn arvon, mikä 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ä toimitettu kokonaisuus ei ole palvelimen tukemassa muodossa, ja pyyntö hylätään.
416 Jos pyyntö sisältää Range-pyyntöotsikon ja kaikki Range-otsikossa määritetyt data-alueet eivät vastaa nykyisen resurssin käytettävissä olevia alueita, eikä pyynnössä määritellä If-Range-pyyntöotsikkoa, palvelimen pitäisi palauttaa tilakoodi 416. Jos pyyntö sisältää Range-pyyntöotsikon, palvelimen pitäisi palauttaa tilakoodi 416. Jos Range käyttää tavualueita, tämä tarkoittaa, että kaikkien pyynnössä määritettyjen data-alueiden ensimmäinen tavu 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 pysty täyttämään Expect-otsakkeessa määritettyä odotettua sisältöä tai palvelin on välityspalvelin, jolla on selkeää näyttöä siitä, että Expectin sisältöä ei voida täyttää nykyisen reitin seuraavassa solmussa.
421 Nykyisen asiakkaan IP-osoitteesta palvelimelle tulevien yhteyksien määrä ylittää palvelimen salliman enimmäismäärän. Yleensä IP-osoite tarkoittaa tässä yhteydessä asiakkaan osoitetta palvelimelta katsottuna (esim. käyttäjän yhdyskäytävän tai välityspalvelimen osoite). Tässä tapauksessa yhteyden laskennassa voi olla mukana useampi kuin yksi 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ä yhteydessä asiakkaan osoitetta palvelimelta katsottuna (esim. käyttäjän yhdyskäytävän tai välityspalvelimen osoite). Tässä tapauksessa yhteyden laskennassa voi olla mukana useampi kuin yksi 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) 423 Lukittu.
424 Nykyinen pyyntö epäonnistui edellisen pyynnön, kuten PROPPATCHin, 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 tilanteen, joka esti sitä suorittamasta pyynnön käsittelyä loppuun. Yleensä tämä ongelma ilmenee, kun palvelimen ohjelmakoodissa on virhe.
501 Palvelin ei tue ominaisuutta, jota nykyinen pyyntö edellyttää. Kun palvelin ei tunnista pyydettyä menetelmää eikä voi tukea 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 yrittää suorittaa pyynnön, ei saa ajoissa vastausta edeltävältä palvelimelta (URI:n tunnistama 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 Transparent Content Negotiation -neuvotteluissa, eikä se siksi 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 saamiseksi vaadittavaa käytäntöä ei ole noudatettu. (RFC 2774)
Oikeus tutustua asiakirjoihin: