| HTTP tilakoodit | tilakoodin merkitys |
|---|
| 100 | asiakaspuolen tulisi jatkaa pyyntöjen lähettämistä. Tämä väliaikainen vastaus käytetään ilmoittamaan asiakaspuolelle, että joihinkin sen pyyntöihin on saatu vastaus palvelimelta eikä niitä ole hylätty. Asiakaspuolen tulisi jatkaa loput pyyntöjen lähettämistä, tai sivuuttaa vastaus, jos pyyntö on suoritettu. Palvelimen on lähetettävä lopullinen vastaus asiakaspuolelle pyynnön suorittamisen jälkeen. |
| 101 | Palvelin on ymmärtänyt asiakkaan pyynnön ja ilmoittaa asiakaspuolelle Upgradepääkkeen avulla käyttääksesi eri protokollaa pyynnön suorittamiseksi. Vastauksen viimeisen tyhjän rivin lähettämisen jälkeen palvelin siirtyy niihin protokolloihin, jotka on määritelty Upgradepääkkeessä. Tällaisia toimenpiteitä tulisi tehdä vain, jos uuden protokollan käyttö on edullisempaa. Esimerkiksi uuden HTTP-version käyttö on edukas vanhalle versiolle tai todelliselle-aikataulutettu ja synkroninen protokolla, joka toimittaa resursseja, jotka hyödyntävät tällaisia ominaisuuksia. |
| 102 | WebDAV:n (RFC) laajennettu status code -koodi 2518) osoittaa, että käsittely jatkuu. |
| 200. | Pyyntö on onnistunut, ja halutut vastausotsakkeet tai tietorakenteet palaavat vastauksessa. |
| 201 | Pyyntö on täytetty, ja uusi resurssi on luotu pyynnön vaatimusten mukaisesti, ja sen URI on palautettu Location-otsakkeessa. Jos vaadittu resurssi ei voi luoda ajallaan, '202 Hyväksytty' tulisi palauttaa. |
| 202 | Palvelin on hyväksynyt pyynnön, mutta sitä ei ole vielä käsitelty. Samalla kuin pyyntö voi hylätä, se voi tai ei suoriteta lopulta. Epäsymmetrisissä toimissa ei ole enempää mukavaa tapaa tehdä tätä kuin lähettää tämä status code. Tavoitteena on palauttaa 'Accepted'. 202 status code -vastaus sallii palvelimen hyväksyä pyyntöjä muiden prosessien (kuten erikoisoperationin) suorittamiseksi.-toiminto, joka suoritetaan vain kerran päivässä) ilman, että asiakaspuolen on pidettävä yhteyttä palvelimeen siihen asti, kun erikoisoperation on valmis. Vastaanottaessa pyynnön käsittelemistä ja palautetta vastauskoodina sallitaan palvelimen hyväksyä pyyntöjä muiden prosessien (kuten erikoisoperationin) suorittamiseksi. 202 tilakoodin, palautetun entiteetin tulisi sisältää tietoja prosessin nykyisestä tilasta sekä viittaus prosessin tilanvalvontamonitoriin tai tilaprediktioon, jotta käyttäjä voi arvioida, onko operaatio suoritettu. |
| 203 | Palvelin käsittelee pyynnön onnistuneesti, mutta palauttaman entiteettipäätteen meta-tiedot eivät ole kelvollinen deterministinen joukko alkuperäispalvelimella, vaan paikallinen tai kolmannen-puolen kopio. Nykyinen tieto voi olla osa- tai ylätulo alkuperäisestä versiosta. Esimerkiksi resursseja sisältävä meta-tieto voi saada alkuperäispalvelimen tietämään meta-super. Tämän tilakoodin käyttö ei ole välttämätöntä ja on sopivaa vain, jos vastaus palauttaa 200 OK ilman tätä tilakoodia. |
| 204 | Palvelin käsittelee pyynnön onnistuneesti, mutta ei tarvitse palauttaa minkäänlaista fyysistä sisältöä ja haluaa palauttaa päivitetyn meta-tiedon. Vastaus voi olla entiteettipäätteen muodossa, joka palauttaa uutta tai päivitettyä meta-tietoa. Jos tämä päätteen tieto on olemassa, se tulisi vastata pyydettyä muuttujaa. Jos asiakaskannan on selain, käyttäjän selain tulisi pitää pyynnön lähettäneen sivun muuttumattomana ilman minkäänlaista asiakirjan näkymän muutosta, vaikka uusi tai päivitetty meta-tieto tulisi soveltaa käyttäjän selaimen aktiiviseen näkymään mukaisesti. Koska 204 vastaus ei saa sisältää minkäänlaista viestirakennetta, se päätyy aina ensimmäiseen tyhjään riviin otsikon jälkeen. |
| 205 | palvelin käsittelee pyynnön onnistuneesti ja palauttaa mitään. Mutta toisin kuin 204 Vastaus, joka palauttaa tämän tilakoodin, vaatii pyynnön tekijän palauttamaan asiakirjan näkymän. Tämä vastaus käytetään pääasiassa lomakkeen välittömään palauttamiseen käyttäjän syötön hyväksymisen jälkeen, jotta käyttäjä voi helposti aloittaa uuden syötön. Kuten 204 vastaus, tämä vastaus estetään myös sisältämästä viestin sisältöä ja päättyy ensimmäiseen tyhjään riviin otsikon jälkeen. |
| 206 | Palvelin on onnistuneesti käsitellyt osan GET-pyynnöstä. HTTP-lataustyökalut, kuten FlashGet tai Xunlei, käyttävät tätä tyyppistä vastausta toteuttaakseen katkaisun jatkumisen tai suuren dokumentin jakamisen useisiin lataussegmentteihin samanaikaiseksi lataamiseksi. Pyyntö tulisi sisältää Alue-otsikon osoittamaan sisällön alueen, jonka asiakaspuoli haluaa, ja se voi sisältää If-Alue pyynnön ehdolla. Vastaus tulisi sisältää seuraavat otsikkokentät: sisältö-Alue osoittaa sisällön alueen, joka palautetaan tässä vastauksessa; jos se on moniosainen-segmentin lataus sisältämällä-Tyyppi multipart/byteranges, jokainen moniosainen segmentti tulisi sisältää-Alue kenttä osoittaa tämän segmentin sisällön alueen. Jos vastaus sisältää-Pituus, sen arvon täytyy vastata todellista määrää bittiä, joka sisältää palautetun sisällön alueen. Päivämäärä ETag ja/tai Content-Location, jos sama pyyntö olisi pitänyt palauttaa 200 vastaus. Expires, Cache-Kontrolli, ja/tai Vary, jos sen arvo voi olla erilainen kuin arvo, joka vastaa muita vastauksia samaan muuttujaan ennen. Jos tämä vastauspyyntö käyttää If-Alue vahva tallennusvahvistus, tämä vastaus ei saa sisältää muita entiteettiohjelmisto-otsikoita; jos tämä vastauspyyntö käyttää If-Alue heikko tallennusvahvistus, tämä vastaus ei saa sisältää muita entiteettiohjelmisto-otsikoita; tämä välttää epäjohdonmukaisuudet tallennetun entiteetin sisällön ja päivitetyn entiteettiohjelmiston tiedon välillä. Muuten, tämä vastaus tulisi sisältää kaikki entiteettiohjelmiston kentät, jotka tulisi palauttaa 200-vastauksesta. Jos ETag tai viimeinen-Muutettu otsikot eivät täsmää tarkasti, asiakaspuolen tallennus tulisi estää yhdistämästä sisältöä, joka palautetaan 206 entiseen tallennettuun sisältöön. Kaikki tallennus, joka ei tue Alue ja sisällön-Alueotsikko estetään tallentamasta vastauksen sisältöä 206 vastaus. |
| 207 | WebDAV (RFC) laajennettu tilakoodi 2518) edustaa sitä, että seuraavan viestin sisältönä on XML-viesti, ja se voi sisältää useita riippumattomia vastauskoodeja riippuen edeltävien alaviestien määrästä.-pyynnöt. |
| 300 | Pyydetty resurssi tarjoaa valikoiman palautusvaihtoehtoja, kuten oma erityinen osoite ja selain-johdettu neuvottelutieto. Käyttäjä tai selain voi valita suosituksen uudelleenohjaukseen. Ellei tämä ole HEAD-pyyntö, vastauksessa tulisi olla entiteetti, joka sisältää luettelon resurssin ominaisuuksista ja osoitteista, joista käyttäjä tai selain voi valita sopivimman uudelleenohjausosoitteen. Tämän entiteetin muoto määritetään Content-Tyyppi. Selain voi automaattisesti tehdä kaikkein sopivimman valinnan vastauksen muodon ja selaimen omien kykyjen perusteella. Totta kai, RFC 2616 spesifikaatiota, eivät määritä, miten tämä automaattinen valinta tulisi suorittaa. Jos palvelin itsessään on jo valinnut suosituksen, palautteen URI tulisi määritellä Location-kenttään; selaimet voivat käyttää tätä Location-arvoa osoitteena automaattiseen uudelleenohjaukseen. Lisäksi, ellei muuta mainita, vastaus on myös tallennettavissa välimuistiin. |
| 301 | Pyydetty resurssi on siirretty pysyvästi uuteen sijaintiin, ja tulevaisuudessa tähän resurssiin viittaamiseen tulisi käyttää tähän vastaukseen palautettuja useita URI:eja. Jos mahdollista, asiakaspuolen linkkieditointikykyinen osa pitäisi muuttaa pyydettävän osoitteen palvelimen palauttamaan osoitteeseen. Ellei muuta mainita, tämä vastaus on myös tallennettavissa välimuistiin. Uusi pysyvä URI tulisi palauttaa vastauksen Location-kenttään. Ellei tämä ole HEAD-pyyntö, vastausentiteetissä tulisi olla hyperlinkki uuteen URI:hin ja lyhyt kuvaus. Jos tämä ei ole GET- tai HEAD-pyyntö, selain ei voi automaattisesti uudelleenohjata käyttäjän vahvistuksesta riippuen, koska pyynnön ehdot voivat muuttua tämän seurauksena. Huomaa: Jotkut selaimet, jotka käyttävät HTTP/1.0-protokollassa, kun he lähettävät POST-pyynnön ja saavat 301 vastaus, seuraava uudelleenohjauspyyntö tulee olemaan GET. |
| 302 | Pyydetty resurssi vastaa nyt väliaikaisesti pyyntöihin eri URI:sta. Koska tällaiset uudelleenohjaukset ovat väliaikaisia, asiakaspuolen tulisi jatkaa tulevien pyyntöjen lähettämistä alkuperäiseen osoitteeseen. Tämä vastaus on tallennettavissa vain, jos sitä on määritelty Cache-Hallinta tai Expires. Uusi väliaikainen URI tulisi palauttaa vastauksen Location-kenttään. Ellei tämä ole HEAD-pyyntö, vastausentiteetissä tulisi olla hyperlinkejä uuteen URI:hin ja lyhyt kuvaus. Jos tämä ei ole GET- tai HEAD-pyyntö, selain estää automaattisen uudelleenohjauksen, ellei sitä vahvisteta käyttäjän toimesta, koska pyynnön ehdot voivat muuttua tämän seurauksena. Huomaa: Vaikka RFC 1945 ja RFC 2068 määritelmät eivät salli asiakaspuolen muuttaa pyynnön menetelmää uudelleenohjauksen yhteydessä, monet olemassa olevat selaimet käsittelevät 302 vastaus 303 vastaus ja käytä GET:ää saadaksesi URI:n, joka on määritelty Locationissa, sivuuttaen alkuperäisen pyyntimenetelmän. Statuskoodit 303 ja 307 lisättiin selventää, mitä palvelin odottaa asiakaspuolelta. |
| 303 | nykyisen pyynnön vastaus löytyy toisesta URI:sta, ja asiakaspuolen tulisi saada GET-pääsy kyseiseen resurssiin. Tämä menetelmä on olemassa pääasiassa-aktivoidaan POST-pyyntiulostulo uudelle resurssille. Tämä uusi URI ei ole korvaava viittaus alkuperäiseen resurssiin. Lisäksi, 303 vastaukset eivät saa olla välimuistissa. Totta kai, toinen pyyntö (uudelleenohjaus) voi olla välimuistissa. Uusi URI tulisi palauttaa vastauksen Location-kenttään. Ellei tämä ole HEAD-pyyntö, vastausentiteetti tulisi sisältää hyperlinkin uuteen URI:hin ja lyhyen kuvauksen. Huomaa: Monet HTTP:n edellä olevat selaimet/1.1 eivät ymmärrä 303 tilan oikein. Jos tarvitset ottaa huomioon näiden selainten vuorovaikutuksen, niin 302 tilakoodi riittää, koska useimmat selaimet käsittelevät 302 vastaukset täsmälleen samalla tavalla kuin yllä oleva määritelmä vaatii asiakaspuolen käsittelemään 303 vastaukset. |
| 304 | Jos asiakaspuoli lähettää ehdollisen GET-pyynnön ja pyyntö on sallittu, ja asiakirjan sisältö ei ole muuttunut (viimeiseltä vierailulta tai pyynnön ehtojen mukaan), palvelimen tulisi palauttaa tämä tilakoodi. 304 vastaukset eivät saa sisältää viestijoukkioita, joten ne päättyvät aina ensimmäiseen tyhjään riviin päätteen jälkeen. Vastauksen täytyy sisältää seuraavat päätteen tiedot: Päivämäärä, ellei tämä palvelin ole varustettu kellolla.
Jos myös kelloa ei ole varustettu palvelin noudattaa näitä sääntöjä, niin välityspalvelin ja asiakaspuoli voivat itse lisätä Päivämäärä-kentän vastaanotettuun vastauspäätteen pääteeseen (RFC:n mukaisesti) 2068), ja välimuistimekanismi toimii hyvin. ETag ja/tai Content-Location, jos sama pyyntö olisi pitänyt palauttaa 200 vastaus. Expires, Cache-Kontrolli, ja/tai Vary, jos sen arvo voi olla erilainen kuin vastausten arvo, jotka vastaavat samaa muuttujaa ennen.
Jos tämä vastauspyyntö käyttää vahvaa välimuistivahvistusta, niin tähän vastausta ei pitäisi sisältää muita entiteettipäätteitä; muuten (esimerkiksi ehdollinen GET-pyyntö käyttää heikkoa välimuistivahvistusta), tähän vastausta ei kielletä sisältämästä muita entiteettipäätteitä; tämä välttää epäjohdonmukaisuudet välimuistissa olevan entiteettisisällön ja päivitetyn entiteettipäätteen tiedon välillä. Jos 304 vastaus viittaa siihen, että yksikkö ei ole tällä hetkellä tallennettuna, tallennusjärjestelmän täytyy sivuuttaa vastaus ja lähettää toistuvia pyyntöjä ilman rajoituksia.
Jos 304 vastaus vastaanotetaan tallennetun kohteen päivittämiseksi, tallennusjärjestelmän täytyy päivittää koko kohta heijastamaan kaikkien vastauksessa päivitettyjen kenttien arvoja. |
| 305 | Pyydetty resurssi täytyy saavuttaa määritetyn välityspalvelimen kautta. Määritetyn välityspalvelimen URI-tiedot annetaan Location-kenttään. Vastaanottaja täytyy lähettää toistuvasti erillinen pyyntö saadakseen vastaavan resurssin tämän välityspalvelimen kautta. Vain alkuperäinen palvelin voi perustaa 305 vastaus. Huomaa: Ei ole selvästi 305 RFC:n vastaus 2068 uudelleenohjata yksittäistä pyyntöä, ja se voidaan perustaa vain alkuperäisessä palvelimessa. Näiden rajoitusten sivuuttaminen voi johtaa vakaviin turvallisuusseuraamuksiin. |
| 306 | Määntelyn uusimmassa versiossa 306 tilakoodi ei enää käytetä. |
| 307 | Pyydetty resurssi vastaa nyt väliaikaisesti pyyntöihin eri URI:n kautta. Koska tällaiset uudelleenohjaukset ovat väliaikaisia, asiakaspuolen täytyy jatkaa tulevien pyyntöjen lähettämistä alkuperäiseen osoitteeseen. Tämä vastaus on vain väliaikaisesti tallennettavissa, jos sitä on määritetty Cache-Hallinta tai Expires. Uusi väliaikainen URI täytyy palauttaa vastauksen Location-kenttään. Ellei tämä ole HEAD-pyyntö, vastaava yksikkö täytyy sisältää hyperlinkin uuteen URI:hin ja lyhyen kuvauksen. Koska jotkut selaimet eivät tunnista 307 vastaus, yllä oleva tieto täytyy lisätä, jotta käyttäjä voi ymmärtää ja pyytää pääsyä uuteen URI:hin.
Jos tämä ei ole GET tai HEAD-pyyntö, selain estää automaattisen uudelleenohjauksen, ellei käyttäjä vahvista sitä, koska pyynnön ehdot voivat muuttua tämän seurauksena. |
| 400 | 1. Semanttiset säännöt ovat väärin, ja palvelin ei voi ymmärtää nykyistä pyyntöä. Ellei muuteta, asiakaspuolen ei tulisi lähettää pyyntöä uudelleen. 2. Pyyntöparametrit ovat väärin. |
| 401 | Nykyinen pyyntö vaatii käyttäjätodennuksen. Vastauksen täytyy sisältää WWW-Authenticate-otsikko pyytämälle resurssille tiedustellakseen käyttäjältä tietoja. Asiakaspuoli voi uudelleenlähettää pyynnön sopivalla Authorization-otsikkotiedolla. Jos nykyinen pyyntö sisältää jo Authorization-sertifikaatteja, 401 vastaus edustaa sitä, että palvelin on hylännyt kyseiset sertifikaatit. Jos 401 vastaus sisältää saman todennuspyynnön kuin edellinen vastaus, ja selain on yrittänyt todennusta vähintään kerran, sitten selain tulisi näyttää käyttäjälle vastauksessa sisältyvän entiteetin tiedot, koska tämä entiteetin tieto voi sisältää relevantteja diagnostisia tietoja. Katso RFC 2617. |
| 402 | Tämä tilausnumero varataan mahdollisille tuleville vaatimuksille. |
| 403 | Palvelin on ymmärtänyt pyynnön, mutta kieltäytynyt sen suorittamisesta. Erilaista kuin 401 vastaus, todennus ei auta, ja pyyntöä ei tulisi toistaa. Jos tämä ei ole HEAD-pyyntö, ja palvelin haluaa pystyä selittämään, miksi pyyntöä ei voida suorittaa, niin hylkäämisen syy tulisi kuvata entiteetissä. Totta kai, palvelin voi myös palauttaa 404 vastaus, jos se ei halua asiakaspuolen saavan minkäänlaisia tietoja. |
| 404 | Pyyntö epäonnistui, ja haluttu resurssi ei löytynyt palvelimelta. Ei ole tietoja, jotka kertoisivat käyttäjälle, onko tilanne tilapäinen vai pysyvä. Jos palvelin on tietoinen tilanteesta, 410 Tilausnumeroa tulisi käyttää ilmoittaakseen vanhalle resurssille, että se on pysyvästi saatavilla ei-käytettävissä jonkin sisäisen konfiguraatiomekanismin vuoksi eikä sillä ole osoitetta, johon siirtymistä. 404 Tilausnumero käytetään laajasti, kun palvelin ei halua paljastaa, miksi pyyntö hylättiin tai ei ole saatavilla muita sopivia vastauksia. |
| 405 | Pyyntölinjassa määritelty pyyntömenetelmä ei voi käyttää vastaavan resurssin pyytämiseen. Vastaus on palautettava Allow-pääte, joka osoittaa listan pyyntömenetelmistä, joita nykyinen resurssi voi hyväksyä. Koska PUT- ja DELETE-menetelmät kirjoittavat resursseja palvelimelle, suurin osa verkkopalvelimista ei tue tai salli oletuksena yllä olevaa pyyntömenetelmää ja palauttaa 405 virhe tällaisille pyynnöille. |
| 406 | Pyydettävän resurssin sisällön ominaisuudet eivät täytä pyynnön otsikkopäätteen asettamia ehtoja, joten vastausentiteettiä ei voida luoda. Ellei tämä ole HEAD-pyyntö, vastaus tulisi palauttaa entiteetti, joka mahdollistaa käyttäjän tai selaimen valitseman sopivimmat entiteetin ominaisuudet ja osoitelistat. Entiteetin muoto määräytyy mediatyypin mukaan, joka on määritelty Content-Tyyppipääte. Selain voi tehdä parhaan valinnan muodon ja omien kykyjensä perusteella. Kuitenkin määrittely ei määritä minkäänlaisia kriteerejä tällaisten automaattisten valintojen tekemiseksi. |
| 407 | Samankaltainen 401 vastauksen, mutta asiakaspuolen on tunnistauduttava välityspalvelimella. Välityspalvelimen on palautettava välityspalvelimen-Tunnista tunnistautumista varten. Asiakaspuoli voi palauttaa välityspalvelimen-Auktorisointipääte tunnistautumista varten. Katso RFC 2617. |
| 408 | Pyyntö aikoiutui. Asiakaspuoli ei suorittanut pyynnön lähettämistä ennen kuin palvelin oli valmis odottamaan. Asiakaspuoli voi lähettää uuden pyynnön milloin tahansa ilman muutoksia. |
| 409 | Pyyntö ei voi suoritua, koska pyydettävän resurssin nykyinen tila aiheuttaa konfliktin. Tämä koodi voidaan käyttää vain, jos käyttäjä otetaan oletuksena kykenevä ratkaisemaan konfliktin ja lähettämään uuden pyynnön. Vastaukseen tulisi sisältyä riittävästi tietoa käyttäjän löytämiseksi konfliktin syy. Konfliktit tapahtuvat yleensä PUT-pyynnöiden käsittelyssä. Esimerkiksi versiossa-tarkistettu ympäristö, jos versiotiedot, jotka liittyvät PUT-lähettämä muutospyyntö tietystä resurssista ristiriidassa aikaisemman (kolmannen)-osapuolen) pyyntö, palvelimen tulisi palauttaa 409 virheilmoitus, joka kertoo käyttäjälle, että pyyntöä ei voitu suorittaa.
Tässä vaiheessa vastausentiteetti todennäköisesti sisältää vertailun kahden ristiriitaisten versioiden välillä, jotta käyttäjä voi uudelleenlähettää yhdistetyn version. |
| 410 | Pyydetty resurssi ei ole enää saatavilla palvelimella eikä sillä ole mitään tunnettua edustusosoitetta. Tämä tilanne tulisi pitää pysyvänä. Jos mahdollista, asiakaspuolen linkkieditointikykyinen puoli tulisi poistaa kaikki viittaukset tähän osoitteeseen käyttäjän luvalla. Jos palvelin ei tiedä tai ei voi määrittää, onko tämä tilanne pysyvä, niin se 404 tilakoodin tulisi käyttää. Ellei muuta ole määritelty, tämä vastaus on tallennettavissa. Tavoitteena on 410 vastaus käytetään pääasiassa auttamaan verkkomestaria ylläpitämään verkkosivustoa, ilmoittamaan käyttäjälle, että resurssi ei ole enää saatavilla, ja että palvelimen omistajalla halutaan poistaa kaikki tähän resurssiin liittyvät etäyhteydet.
Tämä tyyppinen tapahtuma on yleistä ajassa-rajoitettu, arvo-lisättyjä palveluita. Samoin, 410 vastaus käytetään ilmoittamaan asiakaspuolelle, että yksilölle kuuluvat resurssit eivät ole enää saatavilla nykyisellä palvelimella. Totta kai, palvelimen omistajalla on täysin vapaaehtoinen valta merkitä kaikki pysyvästi saatavilla olevat resurssit' 410 Gone ', ja kuinka kauan tämän merkin tulisi säilyttää. |
| 411 | Palvelin kieltäytyy hyväksymästä pyyntöä ilman määritettyä sisältöä-Pituusotsikko. Kun lisätään kelvollista sisältöä-Pituusotsikko, joka ilmaisee pyynnön sisällön pituuden, asiakas voi lähettää pyynnön uudelleen. |
| 412 | Palvelin ei onnistunut täyttämään yhtä tai useampia ehtoja varmistettaessa, että ne annettiin pyynnön otsikkokentässä. Tämä tilakoodi mahdollistaa asiakaspuolen asettaman ehtoja pyydettyyn metadatoihin (pyynnön otsikkokenttään tallennettu tieto) haettaessa resursseja, mikä estää pyyntimenetelmän soveltamisen muihin resursseihin kuin haluttuihin. |
| 413 | Palvelin kieltäytyy käsittelemästä nykyistä pyyntöä, koska pyyntö lähettää enemmän entiteettidataa kuin mitä palvelin on valmis tai kykenee käsittelemään. Tässä tapauksessa palvelin voi sulkea yhteyden estääkseen asiakaspuolen jatkamasta pyynnön lähettämistä. Jos tämä tilanne on tilapäinen, palvelimen tulisi palauttaa uudelleen kokeilemista.-Vastauspäätehteen jälkeen tiedottaakseen asiakaspuolen, kuinka kauan se voi yrittää uudelleen. |
| 414 | Pyydetty URI on pidempi kuin mitä palvelin voi tulkita, joten palvelin kieltäytyy palvelemasta pyyntöä. Tämä on harvinaista, ja yleisiä tapauksia ovat: Lomakkeen lähettäminen, joka olisi pitänyt käyttää POST-metodia, muuttuu GET-metodiksi, mikä aiheuttaa kyselymerkin (kyselymerkkijono) olevan liian pitkän. Uudelleenohjauksen URI "mustat aukot", kuten jokainen uudelleenohjaus käyttää vanhaa URI:ta osana uutta URI:ta, mikä johtaa URI:n olevan liian pitkä useiden uudelleenohjauksien jälkeen. Asiakas yrittää hyökätä palvelimeen turvallisuusongelmien avulla, jotka ovat joissakin palvelimissa.
Tämä tyyppinen palvelin käyttää kiinteää-pituusväliä lukeakseen tai manipuloimaan pyydettyä URI:ta. Kun GET-parametrit ylittävät tietyn arvon, voi tapahtua buffer-ylivuoto, mikä johtaa määrittelemättömän koodin suorittamiseen [1]. Palvelimet, joilla ei ole tällaista haavoittuvuutta, tulisi palauttaa 414 tilakoodi. |
| 415 | Nykyisen pyynnön metodin ja pyydettävän resurssin osalta pyynnössä toimitettu entiteetti ei ole muodossa, jota palvelin tukee, joten pyyntö hylätään. |
| 416 | Jos pyynnössä on rajahäntä ja mikään Range-häntään määritelty tietorakenne ei ole yhteneväisenä nykyisen resurssin saatavilla olevan alueen kanssa, ja If-Rajahäntä ei ole määritelty pyynnössä, palvelimen tulisi palauttaa 416 tilakoodin kanssa. Jos Range käyttää bittialueita, tämä tilanne tarkoittaa, että pyynnössä määritellyt kaikki datan alueiden ensimmäinen bittiasema ylittää nykyisen resurssin pituuden. Palvelimen tulisi myös sisällyttää Content-Range-entiteettipäätteen yhdessä 416 tilakoodi ilmaisemaan nykyisen resurssin pituuden. Tämä vastaus estetään myös käyttämästä multipart/byteranges sen sisällönä-Tyyppi. |
| 417 | Pyyntöjen otsikkoon määritelty odotettu sisältö ei voida tyydyttää palvelimella, tai palvelin on välityspalvelin, jolla on selkeä todiste, että odotettu sisältö ei voida tyydyttää seuraavassa solmussa nykyisessä reitissä. |
| 421 | Internet-protokollan osoitteesta, jossa nykyinen asiakaspuoli sijaitsee, tulojen määrä ylittää palvelimen salliman enimmäismäärän. Yleensä tässä Internet-protokollan osoite viittaa palvelimesta nähtyyn asiakaspuolen osoitteeseen (kuten käyttäjän liittymä- tai välityspalvelimen osoitteeseen). Tässä tapauksessa yhteyden lukumäärä voi sisältää useita loppukäyttäjiä. |
| 422 | Internet-protokollan osoitteesta, jossa nykyinen asiakaspuoli sijaitsee, tulojen määrä ylittää palvelimen salliman enimmäismäärän. Yleensä tässä Internet-protokollan osoite viittaa palvelimesta nähtyyn asiakaspuolen osoitteeseen (kuten käyttäjän liittymä- tai välityspalvelimen osoitteeseen). Tässä tapauksessa yhteyden lukumäärä voi sisältää useita loppukäyttäjiä. |
| 422 | Pyyntö oli muodostettu oikein, mutta sitä ei voitu vastata semanttisen virheen vuoksi. (RFC 4918 WebDAV) 423 Lukittu Tämänhetkinen resurssi on lukittu. (RFC 4918 WebDAV) |
| 424 | Nykyinen pyyntö epäonnistui aikaisemmassa pyynnössä tapahtuneen virheen vuoksi, kuten PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Määritelty WebDav Advanced Collections -luonnoksessa, mutta ei WebDAV Sequential Set -protokollassa (RFC 3658). |
| 426 | Asiakaspuoli tulisi vaihtaa TLS:hen/1.0. (RFC 2817) |
| 449 | Microsoftin laajentama, pyyntöjä tulisi uudelleen yrittää suorittaa sopivan toiminnon jälkeen. |
| 500 | Palvelin kohtasi odottamattoman tilanteen, joka esti sen suorittamasta pyyntöä. Yleensä tämä ongelma ilmenee, kun palvelimen koodi epäonnistuu. |
| 501 | Palvelin ei tue nykyisessä pyynnössä vaadittua ominaisuutta. Kun palvelin ei voi tunnistaa pyydettyä metodia eikä tukea sen resurssipyyntöä. |
| 502 | Kun verkkoserver, joka toimii liittymä- tai välityspalvelimena, yrittää suorittaa pyynnön, se saa pätemättömän vastauksen yläpuoliselta palvelimelta. |
| 503 | Palvelin ei tällä hetkellä voi käsitellä pyyntöjä tilapäisen palvelimen huollon tai ylikuormituksen vuoksi. Tämä tila on tilapäinen ja palautuu jonkin ajan kuluttua. Jos viiveaika voidaan ennustaa, vastaukseen voidaan sisällyttää Retry-Otsikkoa ilmaisemaan viiveaikaa. Jos tämä Retry-Tiedon antamatta, asiakaspuoli tulisi käsittelemään sitä kuin 500 vastaus. Huomautus: Olemassa olevan 503 tilakoodi ei tarkoita, että palvelimen on käytettävä sitä ylikuormituksen yhteydessä. Jotkut palvelimet haluavat vain kieltää asiakkaan yhteyden. |
| 504 | Kun verkkoserveri, joka toimii liittymä- tai välityspalvelimena, yrittää suorittaa pyynnön, se ei saa saada vastausta ylätason palvelimelta (määritetty URI:n kautta, kuten HTTP, FTP, LDAP) tai toisesta palvelimesta (kuten DNS) ajoissa. Huomautus: Jotkut välityspalvelimet palauttavat 400 tai 500 virhe, kun DNS-kysely aikaa ylittyy |
| 505 | Palvelin ei tue, tai kieltäytyy tukemasta, pyynnössä käytettävää HTTP-versiota. Tämä tarkoittaa, että palvelin ei voi tai ei halua käyttää samaa versiota kuin asiakaspuoli. Vastaukseen tulisi sisältyä olio, joka kuvaa, miksi versio ei ole tuettu ja mitä protokollia palvelin tukee. |
| 506 | Laajennettu läpinäkyvän sisällön neuvottelusopimuksen (RFC 2295), tämä edustaa palvelimen sisäistä konfiguraatiorikkoa: pyydetty neuvottelumuuttuja resurssi on konfiguroitu käyttämään itseään läpinäkyvässä sisällön neuvottelussa, ja siksi se ei ole sopiva kohde neuvotteluprosessissa. |
| 507 | Palvelin ei voi tallentaa pyynnön suorittamiseen tarvittavaa sisältöä. Tämä tila on tilapäinen. WebDAV (RFC 4918) |
| 509 | Palvelin on saavuttanut bändileveyden rajan. Tämä ei ole virallinen tilakoodi, mutta sitä käytetään edelleen laajasti. |
| 510 | Resurssien saamiseen vaaditut politiikat eivät ole täyttyneet. (RFC 2774) |
