HTTP durum kodu, bir talebe yan?t olarak sunucu taraf?ndan d?ndürülen ve talebin sonucunu tan?mlamak i?in kullan?lan 3 basamakl? bir koddur. Bu ara?, geli?tiriciler, operasyon ve bak?m personeli ve a? teknolojisi ??renenler i?in uygun standart bir s?n?fland?rma ve senaryo yorumlamas? sa?lar.
Tüm a??klamalar RFC standart belgesine dayand?r?larak b?lgesel ifade farkl?l?klar? ?nlenmi? ve dünyan?n her yerindeki kullan?c?lar?n ayn? ?eyi anlamas? sa?lanm??t?r.
| Http Durum Kodlar? | Durum Kodu Anlam? |
|---|---|
| 100 | ?stemci istek g?ndermeye devam etmelidir. Bu ge?ici yan?t, istemciye iste?inin bir k?sm?n?n sunucu taraf?ndan al?nd???n? ve reddedilmedi?ini bildirmek i?in kullan?l?r. ?stemci, iste?in geri kalan?n? g?ndermeye devam etmeli veya istek tamamland?ysa bu yan?t? yok saymal?d?r. Sunucu, istek tamamland???nda istemciye son bir yan?t g?ndermelidir. |
| 101 | Sunucu, istemcinin iste?ini anlam??t?r ve iste?i tamamlamak i?in farkl? bir protokol kullan?ld???n? Yükseltme ba?l??? arac?l???yla istemciye bildirecektir. Yan?t?n son bo? sat?r?n? g?nderdikten sonra, sunucu Yükseltme ba?l???nda tan?mlanan protokollere ge?ecektir. Bu yaln?zca yeni protokole ge?mek daha avantajl?ysa yap?lmal?d?r. ?rne?in, HTTP'nin yeni bir sürümüne ge?mek eski bir sürüme g?re avantajl? olabilir veya bu tür ?zelliklerden yararlanan kaynaklar? sunmak i?in ger?ek zamanl?, e?zamanl? bir protokole ge?mek avantajl? olabilir. |
| 102 | WebDAV (RFC 2518) taraf?ndan geni?letilen durum kodlar?, i?lemin devam edece?ini g?sterir. |
| 200 | ?stek ba?ar?l? olmu?tur ve istek taraf?ndan istenen yan?t ba?l?klar? veya veri g?vdesi yan?tla birlikte d?ndürülecektir. |
| 201 | ?stek yerine getirildi ve iste?e yan?t olarak yeni bir kaynak olu?turuldu ve URI'si Konum ba?l???yla birlikte d?ndürüldü. ?stenen kaynak zaman?nda olu?turulamazsa, a?a??dakiler d?ndürülmelidir'202 Accepted'。 |
| 202 | Sunucu iste?i kabul etmi?tir, ancak henüz i?leme koymam??t?r. Reddedilebilece?i gibi, istek sonunda yürütülebilir veya yürütülmeyebilir. E?zamans?z i?lemler s?z konusu oldu?unda, bu durum kodunu g?ndermekten daha uygun bir ?ey yoktur. Bir 202 yan?t? d?ndürmenin amac?, istemcinin toplu i?lem tamamlanana kadar sunucuyla ba?lant?y? sürdürmek zorunda kalmadan sunucunun di?er i?lemlerden gelen istekleri (günde yaln?zca bir kez yürütülen toplu i?lem tabanl? bir i?lem gibi) kabul etmesine izin vermektir. ??lem i?in bir talebi kabul eden ve 202 durum kodunu d?ndüren bir yan?t, kullan?c?n?n i?lemin tamamlan?p tamamlanmad???n? tahmin edebilmesi i?in, d?ndürülen varl?kta i?lemin mevcut durumunu g?steren baz? bilgilerin yan? s?ra bir i?lem durumu izleyicisine veya durum tahminine bir i?aret?i i?ermelidir. |
| 203 | Sunucu iste?i ba?ar?yla i?lemi?tir, ancak d?ndürülen varl?k ba?l??? meta bilgileri orijinal sunucuda ge?erli olan kesin bir küme de?il, yerel veya ü?üncü bir taraftan al?nan bir kopyad?r. Ge?erli bilgi orijinalin bir alt kümesi veya üst kümesi olabilir. ?rne?in, kaynak i?eren meta veriler, kaynak sunucunun meta bilgileri süper bilmesine neden olabilir. Bu durum kodunun kullan?lmas? gerekli de?ildir ve yaln?zca yan?t?n bu kod olmadan 200 OK d?ndürmesi durumunda uygundur. |
| 204 | Sunucu iste?i ba?ar?yla i?ledi, ancak herhangi bir fiziksel i?erik d?ndürmesi gerekmiyor ve güncellenmi? meta bilgileri d?ndürmek istiyor. Yan?t, varl?k ba?l?klar? bi?iminde yeni veya güncellenmi? meta bilgileri d?ndürebilir. Bu ba?l?klar mevcutsa, istenen de?i?kenlere kar??l?k gelmelidir. ?stemci bir taray?c?ysa, kullan?c?n?n taray?c?s?, belirtime g?re yeni veya güncellenmi? meta bilgiler kullan?c?n?n taray?c?s?n?n etkin g?rünümündeki belgeye uygulanacak olsa bile, belge g?rünümünde herhangi bir de?i?iklik yapmadan iste?in g?nderildi?i sayfay? korumal?d?r. 204 yan?t?n?n herhangi bir mesaj g?vdesi i?ermesi yasak oldu?undan, her zaman mesaj ba?l???ndan sonraki ilk bo? sat?rla biter. |
| 205 | Sunucu iste?i ba?ar?yla i?ler ve hi?bir ?ey d?ndürmez. Ancak, 204 yan?t?ndan farkl? olarak, bu durum kodunu d?ndüren yan?t, istek sahibinden belge g?rünümünü s?f?rlamas?n? ister. Bu yan?t ?ncelikle kullan?c? girdisini kabul ettikten hemen sonra formu s?f?rlamak i?in kullan?l?r, b?ylece kullan?c? kolayca ba?ka bir girdi ba?latabilir. 204 yan?t? gibi, bu yan?t?n da herhangi bir mesaj g?vdesi i?ermesi yasakt?r ve mesaj ba?l???ndan sonraki ilk bo? sat?rla biter. |
| 206 | Sunucu GET iste?inin bir k?sm?n? ba?ar?yla i?lemi?tir. FlashGet veya Thunderbolt gibi HTTP indirme ara?lar?, aral?kl? indirmeler ger?ekle?tirmek veya büyük bir dosyay? ayn? anda birden fazla indirmeye b?lmek i?in bu yan?t türünü kullan?r. ?stek, istemcinin almak istedi?i i?erik aral???n? belirtmek i?in bir Aral?k ba?l??? i?ermelidir ve istek ko?ulu olarak bir If-Range i?erebilir. Yan?t a?a??daki ba?l?k alanlar?n? i?ermelidir: Bu yan?tta d?ndürülen i?eri?in kapsam?n? belirtmek i?in Content-Range veya Content-Type'? multipart/byteranges olan ?ok par?al? indirmelerde, her ?ok par?al? segmentte o segmentteki i?eri?in kapsam?n? belirtmek i?in bir Content-Range alan?. Yan?t bir Content-Length i?eriyorsa, de?eri d?ndürdü?ü i?erik aral???ndaki ger?ek bayt say?s?yla e?le?melidir. Expires, Cache-Control ve/veya Vary, de?erleri ayn? de?i?kenlere sahip di?er ?nceki yan?tlar?n de?erlerinden farkl? olabilir. Bu yan?t, istek gü?lü If-Range ?nbellek do?rulamas? kullan?yorsa di?er varl?k ba?l?klar?n? i?ermemelidir ve istek zay?f If-Range ?nbellek do?rulamas? kullan?yorsa di?er varl?k ba?l?klar?n? i?ermemelidir; bu, ?nbelle?e al?nan varl?k i?eri?i ile güncellenen varl?k ba?l??? bilgileri aras?ndaki tutars?zl?klar? ?nler. Aksi takdirde, bu yan?t 200 yan?t?nda d?ndürülmesi gereken tüm varl?k ba?l?k alanlar?n? i?ermelidir. ETag veya Last-Modified ba?l?klar? tam olarak e?le?mezse, istemci taraf? ?nbelle?i 206 yan?t?nda d?ndürülen i?eri?in daha ?nce ?nbelle?e al?nm?? i?erikle birle?tirilmesine izin vermemelidir. Range ve Content-Range ba?l?klar?n? desteklemeyen herhangi bir ?nbelle?in 206 yan?t? taraf?ndan d?ndürülen i?eri?i ?nbelle?e almas? yasakt?r. |
| 207 | WebDAV taraf?ndan geni?letilen durum kodlar?(RFC 2518) WebDAV taraf?ndan geni?letilen durum kodu, sonraki mesaj g?vdesinin bir XML mesaj? olaca?? ve ?nceki alt taleplerin say?s?na ba?l? olarak bir dizi ayr? yan?t kodu i?erebilece?i anlam?na gelir. |
| 300 | Talep edilen kayna??n, her biri kendi ?zel adresine ve taray?c? odakl? müzakere bilgilerine sahip bir dizi alternatif yan?t? vard?r. Yeniden y?nlendirme i?in tercih edilen bir adres se?mek kullan?c?ya veya taray?c?ya ba?l?d?r. Bu bir HEAD iste?i olmad??? sürece, yan?t, kullan?c?n?n veya taray?c?n?n en uygun yeniden y?nlendirme adresini se?ebilece?i kaynak ?zelliklerinin ve adreslerinin bir listesi olan bir varl?k i?ermelidir. Bu varl???n bi?imi Content-Type tan?m?n?n bi?imi taraf?ndan belirlenir. Taray?c?, yan?t?n bi?imine ve taray?c?n?n kendi yeteneklerine g?re en uygun se?imi otomatik olarak yapabilir. Elbette, RFC 2616 spesifikasyonu bu otomatik se?imin nas?l yap?lmas? gerekti?ini belirtmez. Sunucunun kendisinin zaten tercih edilen bir d?nü? se?ene?i varsa, d?nü?ün URI'si Konum'da belirtilmelidir; taray?c?lar bu Konum de?erini otomatik y?nlendirme i?in adres olarak kullanabilir. Ayr?ca, aksi belirtilmedik?e yan?t ?nbelle?e al?nabilir. |
| 301 | ?stenen kaynak kal?c? olarak yeni konuma ta??nm??t?r ve gelecekte yap?lacak tüm referanslar bu yan?tta d?ndürülen ?e?itli URI'lerden birini kullanmal?d?r. Mümkünse, ba?lant? düzenleme ?zelliklerine sahip istemciler istenen adresi otomatik olarak sunucudan d?ndürülen adresle de?i?tirmelidir. Aksi belirtilmedik?e bu yan?t da ?nbelle?e al?nabilir. Yeni kal?c? URI, yan?t?n Konum alan?nda d?ndürülmelidir. Bu bir HEAD iste?i olmad??? sürece, yan?t varl??? yeni URI'ye bir k?prü ve k?sa bir a??klama i?ermelidir. Bu bir GET veya HEAD iste?i de?ilse, kullan?c? taraf?ndan onaylanmad?k?a taray?c?n?n otomatik olarak yeniden y?nlendirme yapmas? yasakt?r, ?ünkü sonu? olarak iste?in ko?ullar? de?i?ebilir. Not: HTTP/1.0 protokolünü kullanan baz? taray?c?lar i?in, bir POST iste?i g?nderip 301 yan?t? ald?klar?nda, bir sonraki y?nlendirme iste?i GET olacakt?r. |
| 302 | ?stenen kaynak art?k iste?e ge?ici olarak farkl? bir URI'den yan?t verir. Bu y?nlendirme ge?ici oldu?undan, istemci gelecekteki isteklerini orijinal adrese g?ndermeye devam etmelidir. Yan?t yaln?zca Cache-Control veya Expires ile belirtilmi?se ?nbelle?e al?nabilir. Yeni ge?ici URI, yan?t?n Konum alan?nda d?ndürülmelidir. Bu bir HEAD iste?i olmad??? sürece, yan?t varl??? yeni URI'ye bir k?prü ve k?sa bir a??klama i?ermelidir. Bu bir GET veya HEAD iste?i de?ilse, kullan?c? taraf?ndan onaylanmad?k?a taray?c?n?n otomatik olarak yeniden y?nlendirme yapmas? yasakt?r, ?ünkü sonu? olarak iste?in ko?ullar? de?i?ebilir. Not: RFC 1945 ve RFC 2068 spesifikasyonlar? istemcinin yeniden y?nlendirme s?ras?nda iste?in y?ntemini de?i?tirmesine izin vermese de, mevcut bir?ok taray?c? 302 yan?t?n? 303 yan?t? olarak de?erlendirir ve orijinal iste?in y?ntemini g?z ard? ederek Konum'da belirtilen URI'ye eri?mek i?in GET kullan?r. Sunucunun istemciden bekledi?i yan?t? netle?tirmek i?in 303 ve 307 durum kodlar? eklenmi?tir. |
| 303 | Ge?erli iste?in yan?t? ba?ka bir URI'de bulunabilir ve istemci GET kullanarak bu kayna?a eri?melidir. Bu y?ntem, ?ncelikle komut dosyas? taraf?ndan etkinle?tirilen POST iste?i ??kt?s?n?n yeni bir kayna?a y?nlendirilmesine izin vermek i?in mevcuttur. Bu yeni URI, orijinal kayna??n yerine ge?ecek bir referans de?ildir. Ayr?ca, 303 yan?t?n?n ?nbelle?e al?nmas?na izin verilmez. Elbette, ikinci istek (yeniden y?nlendirme) ?nbelle?e al?nabilir. Yeni URI, yan?t?n Konum alan?nda d?ndürülmelidir. Bu bir HEAD iste?i olmad??? sürece, yan?t varl??? yeni URI'ye bir k?prü ve k?sa bir a??klama i?ermelidir. Not: HTTP/1.1'den ?nceki bir?ok taray?c? 303 durumunu düzgün bir ?ekilde anlamamaktad?r. Bu taray?c?larla etkile?imin dikkate al?nmas? gerekiyorsa, 302 durum kodu ?al??mal?d?r, ?ünkü ?o?u taray?c? 302 yan?t?n? tam olarak yukar?daki belirtimin istemcinin 303 yan?t?n? i?lemesini gerektirdi?i ?ekilde i?ler. |
| 304 | Bu durum kodu, istemci ko?ullu bir GET iste?i g?nderirse ve iste?e izin verilirse ve belgenin i?eri?i de?i?memi?se (son ziyaretten bu yana veya iste?in ko?ullar?na g?re) sunucu taraf?ndan d?ndürülmelidir. 304 yan?tlar?n?n bir mesaj g?vdesi i?ermesi yasakt?r ve bu nedenle her zaman mesaj?n ba?l???ndan sonraki ilk bo? sat?rla biter. Yan?t a?a??daki ba?l?k bilgilerini i?ermelidir: Sunucunun saati yoksa tarih. Sunucunun bu kurallara uyan bir saati yoksa, proxy sunucusu ve istemci gelen yan?t ba?l???na Tarih alan?n? kendileri ekleyebilir (RFC 2068'de belirtildi?i gibi) ve ?nbelle?e alma mekanizmas? düzgün ?al???r.ETag ve/veya Content-Location, ayn? iste?in 200 yan?t? d?ndürmesi gerekiyorsa. Expires, Cache-Control ve/veya Vary, de?erleri ayn? de?i?kenlere sahip di?er ?nceki yan?tlar?n de?erlerinden farkl? olabiliyorsa. Yan?t iste?i gü?lü ?nbellek do?rulamas? kullan?yorsa, yan?t ek varl?k ba?l?klar? i?ermemelidir; aksi takdirde (?rne?in, ko?ullu bir GET iste?i zay?f ?nbellek do?rulamas? kullan?yorsa), yan?t?n ek varl?k ba?l?klar? i?ermesi yasakt?r; bu, ?nbelle?e al?nan varl?k i?eri?i ile güncellenen varl?k ba?l??? bilgileri aras?ndaki tutars?zl?klar? ?nler. 304 yan?t? bir varl???n o anda ?nbelle?e al?nmad???n? g?steriyorsa, ?nbellekleme sistemi yan?t? yok saymal? ve iste?i k?s?tlama olmadan tekrarlamal?d?r. Bir ?nbellek giri?inin güncellenmesini talep eden bir 304 yan?t? al?n?rsa, ?nbellekleme sistemi, yan?tta güncellenen tüm alanlar?n de?erlerini yans?tmak i?in tüm giri?i güncellemelidir. |
| 305 | ?stenen kayna?a belirtilen bir proxy arac?l???yla eri?ilmelidir. Konum alan? belirtilen proxy'nin URI'si hakk?nda bilgi verir ve al?c?n?n bu proxy arac?l???yla kayna?a eri?mek i?in tekrar tekrar ayr? bir istek g?ndermesi gerekir. Yaln?zca orijinal sunucu 305 yan?t? olu?turabilir. Not: RFC 2068'de 305 yan?t?n?n tek bir iste?i y?nlendirmek i?in tasarland??? ve yaln?zca orijinal sunucu taraf?ndan olu?turulabilece?i a??k de?ildir. Bu k?s?tlamalar?n g?z ard? edilmesi ciddi güvenlik sonu?lar?na yol a?abilir. |
| 306 | Spesifikasyonun en son sürümünde, 306 durum kodu art?k kullan?lmamaktad?r. |
| 307 | Talep edilen kaynaklar art?k farkl? URI'lerden gelen taleplere ge?ici olarak yan?t vermektedir. Bu y?nlendirme ge?ici oldu?undan, istemciler gelecekteki isteklerini orijinal adrese g?ndermeye devam etmelidir. Bu yan?t yaln?zca Cache-Control veya Expires ile belirtilmi?se ?nbelle?e al?nabilir. Yeni ge?ici URI, yan?t?n Konum alan?nda d?ndürülmelidir. Bu bir HEAD iste?i olmad??? sürece, yan?t varl??? yeni URI'ye bir k?prü ve k?sa bir a??klama i?ermelidir. Baz? taray?c?lar 307 yan?t?n? tan?mad???ndan, kullan?c?n?n yeni URI'yi anlayabilmesi ve eri?im talep edebilmesi i?in yukar?daki bilgilerin eklenmesi gerekir. Bu bir GET veya HEAD iste?i de?ilse, taray?c?, kullan?c? taraf?ndan onaylanmad?k?a otomatik y?nlendirmeyi yasaklar, ?ünkü iste?in ko?ullar? de?i?ebilir. |
| 400 | 1, semantik hata, mevcut istek sunucu taraf?ndan anla??lam?yor. De?i?tirilmedi?i sürece, istemci iste?i tekrarlamamal?d?r. 2, istek parametreleri yanl??. |
| 401 | Ge?erli istek kullan?c? kimlik do?rulamas? gerektiriyor. Yan?t, kullan?c? bilgilerini sormak i?in istenen kaynak i?in bir WWW-Authenticate ba?l??? i?ermelidir. ?stemci, uygun Yetkilendirme üst bilgisi ile bir iste?i yeniden g?nderebilir. Mevcut istek zaten Yetkilendirme kimlik bilgilerini i?eriyorsa, 401 yan?t? sunucunun bu kimlik bilgilerinin reddedildi?ini do?rulad??? anlam?na gelir. 401 yan?t? ?nceki yan?tla ayn? kimlik do?rulama sorgusunu i?eriyorsa ve taray?c? zaten en az bir kimlik do?rulama denemesi yapm??sa, bu varl?k bilgileri ilgili tan?lama bilgilerini i?erebilece?inden, taray?c? kullan?c?ya yan?tta yer alan varl?k bilgilerini g?stermelidir. RFC 2617'ye bak?n. |
| 402 | Bu durum kodu gelecekteki olas? gereksinimler i?in ayr?lm??t?r. |
| 403 | Sunucu iste?i anlam??t?r, ancak yürütmeyi reddeder. 401 yan?t?ndan farkl? olarak, kimlik do?rulama herhangi bir yard?m sa?lamaz ve istek yeniden g?nderilmemelidir. Bu bir HEAD iste?i de?ilse ve sunucu iste?in neden ger?ekle?tirilemedi?ini s?yleyebilmek istiyorsa, reddetme nedeni varl?kta a??klanmal?d?r. Elbette, sunucu istemcinin herhangi bir bilgi almas?n? istemiyorsa 404 yan?t? da d?ndürebilir. |
| 404 | ?stek ba?ar?s?z oldu, istenen kaynak sunucuda bulunamad?. Kullan?c?ya durumun ge?ici mi yoksa kal?c? m? oldu?unu s?yleyecek bir bilgi yoktur. Sunucu durumun fark?ndaysa, sunucuya baz? dahili yap?land?rma mekanizmalar? nedeniyle eski kayna??n kal?c? olarak kullan?lamad???n? ve kullan?labilir bir y?nlendirme olmad???n? bildirmek i?in 410 durum kodunu kullanmal?d?r. 404, sunucu iste?in neden reddedildi?ini a??klamak istemedi?inde veya ba?ka uygun bir yan?t olmad???nda yayg?n olarak kullan?l?r. |
| 405 | ?stek sat?r?nda belirtilen istek y?ntemi, ilgili kayna?? istemek i?in kullan?lamaz. Yan?t, ge?erli kaynak i?in kabul edilebilir istek y?ntemlerinin listesini g?steren bir Allow ba?l??? d?ndürmelidir. PUT ve DELETE y?ntemleri sunucu üzerindeki kayna?a yazd???ndan, ?o?u web sunucusu bu istek y?ntemlerini desteklemez veya varsay?lan olarak bunlara izin vermez ve bu tür istekler i?in 405 hatas? d?ndürür. |
| 406 | ?stenen kayna??n i?erik ?zellikleri istek ba?l???ndaki ko?ullar? kar??lamaz ve bir yan?t varl??? olu?turulamaz. Bu bir HEAD iste?i de?ilse, yan?t en uygun varl?k ?zelliklerini i?eren bir varl?k ve kullan?c?n?n veya taray?c?n?n se?ebilece?i bir adres listesi d?ndürmelidir. Varl???n bi?imi Content-Type ba?l???nda tan?mlanan ortam türüne g?re belirlenir. Taray?c?, bi?ime ve kendi yeteneklerine g?re en iyi se?imi yapabilir. Ancak, spesifikasyon bu tür otomatik se?imler yapmak i?in herhangi bir kriter tan?mlamaz. |
| 407 | 401 yan?t?na benzer, ancak istemcinin proxy sunucusuyla kimlik do?rulamas? yapmas? gerekir. Proxy sunucusu kimlik sorgulamas? i?in bir Proxy-Kimlik Do?rulama d?ndürmelidir. ?stemci kimlik do?rulama i?in bir Proxy-Authorisation ba?l??? d?ndürebilir. RFC 2617'ye bak?n. |
| 408 | ?stek zaman a??m?. ?stemci, sunucunun beklemeye haz?r oldu?u süre i?inde bir iste?i tamamlayamad?. ?stemci herhangi bir de?i?iklik yapmadan istedi?i zaman iste?i yeniden g?nderebilir. |
| 409 | ?stek, istenen kayna??n ge?erli durumuyla bir ?ak??ma nedeniyle tamamlanamad?. Bu kodun yaln?zca kullan?c?n?n ?ak??may? ??zebilece?i ve yeni bir istek g?nderebilece?i dü?ünülüyorsa kullan?lmas?na izin verilir. Yan?t, kullan?c?n?n ?ak??man?n kayna??n? ke?fetmesi i?in yeterli bilgi i?ermelidir. ?ak??malar genellikle PUT isteklerinin i?lenmesi s?ras?nda ortaya ??kar. ?rne?in, bir sürüm kontrol ortam?nda, ?nceki (ü?üncü taraf) bir istekle ?ak??an sürüm bilgilerine sahip belirli bir kayna?? de?i?tirmek i?in g?nderilen bir PUT, kullan?c?ya iste?in tamamlanamad???n? bildiren bir 409 hatas? d?ndürmelidir. Bu durumda, yan?t varl???n?n iki ?ak??an sürüm aras?ndaki farklar?n bir kar??la?t?rmas?n? i?ermesi muhtemeldir, b?ylece kullan?c? yeni, birle?tirilmi? sürümü yeniden g?nderebilir. |
| 410 | ?stenen kaynak art?k sunucuda mevcut de?ildir ve bilinen bir y?nlendirme adresi yoktur. B?yle bir durum kal?c? olarak de?erlendirilmelidir. Mümkünse, ba?lant? düzenleme ?zelliklerine sahip istemciler, kullan?c?n?n izniyle bu adrese yap?lan tüm referanslar? kald?rmal?d?r. Sunucu durumun kal?c? olup olmad???n? bilmiyorsa veya belirleyemiyorsa, 404 durum kodu kullan?lmal?d?r. Aksi belirtilmedik?e, bu yan?t ?nbelle?e al?nabilir. 410 yan?t?n?n amac?, ?ncelikle kullan?c?ya kayna??n art?k mevcut olmad???n? ve sunucu sahibinin kayna?a olan tüm uzak ba?lant?lar?n da silinmesini istedi?ini bildirerek web y?neticisinin siteyi sürdürmesine yard?mc? olmakt?r. Bu tür olaylar zaman s?n?rl?, katma de?erli hizmetlerde yayg?nd?r. Benzer ?ekilde 410 yan?t?, istemciye bir ki?iye ait bir kayna??n mevcut sunucu sitesinde art?k mevcut olmad???n? bildirmek i?in kullan?l?r. Elbette, kal?c? olarak kullan?lamayan tüm kaynaklar?n bu ?ekilde i?aretlenmesi gerekip gerekmedi?i ve ne kadar süreyle bu ?ekilde tutulmas? gerekti?i sorusu da ?nemlidir.'410 Gone'， ve ne kadar süreyle muhafaza edilmesi gerekti?i tamamen sunucu sahibine ba?l?d?r. |
| 411 | Sunucu, Content-Length ba?l??? tan?mlanmam?? istekleri kabul etmeyi reddeder. ?stemci, istek mesaj? g?vdesinin uzunlu?unu belirten ge?erli bir Content-Length ba?l??? ekledikten sonra iste?i yeniden g?nderebilir. |
| 412 | Sunucu, iste?i do?rularken iste?in ba?l?k alan?nda verilen ?nko?ullardan birini veya daha fazlas?n? kar??layamad?. Bu durum kodu, istemcinin bir kaynak elde ederken iste?in meta bilgilerinde (istek ba?l?k alan? verileri) ?n ko?ullar belirlemesine olanak tan?r, b?ylece istek y?nteminin istedi?i i?erik d???ndaki kaynaklara uygulanmas?n? engeller. |
| 413 | Sunucu mevcut iste?i i?lemeyi reddeder ?ünkü istek sunucunun isteyebilece?inden veya i?leyebilece?inden daha fazla fiziksel veri g?nderir. Bu durumda sunucu, istemcinin iste?i g?ndermeye devam etmesini ?nlemek i?in ba?lant?y? kapatabilir. Durum ge?ici ise, sunucu istemciye yeniden denemek i?in ne kadar zaman? oldu?unu bildirmek i?in bir Retry-After ba?l??? d?ndürmelidir. |
| 414 | ?stek URI'si sunucunun yorumlayabilece?inden daha uzundur, bu nedenle sunucu iste?i sunmay? reddeder. Bu nadir bir durumdur ve genellikle POST y?ntemi kullan?lmas? gereken bir form g?nderimi GET y?ntemine d?nü?tü?ünde ve uzun bir Sorgu Dizesi ile sonu?land???nda ortaya ??kar. Y?nlendirme URI "kara delikleri", ?rne?in her y?nlendirme i?in eski URI'nin yeni URI'nin bir par?as? olarak kullan?lmas?, birka? y?nlendirmeden sonra uzun bir URI ile sonu?lan?r. ?stemciler, baz? sunucularda bulunan güvenlik a??klar?ndan yararlanarak sunuculara sald?rmaya ?al??maktad?r. Bu tür sunucular, istenen URI'yi okumak veya de?i?tirmek i?in sabit uzunlukta bir arabellek kullan?r; bu da GET parametresi belirli bir de?eri a?t???nda arabellek ta?mas?na neden olarak keyfi kod yürütülmesine yol a?abilir.[1]。 Bu tür güvenlik a??klar? olmayan sunucular 414 durum kodu d?ndürmelidir. |
| 415 | ?u anda istenen y?ntem ve istenen kaynak i?in, istekte g?nderilen varl?k sunucu taraf?ndan desteklenen bir bi?imde de?ildir ve istek reddedilir. |
| 416 | ?stek bir Aral?k istek ba?l??? i?eriyorsa ve Aral?k'ta belirtilen veri aral?klar? ge?erli kaynak i?in kullan?labilir aral?klarla ?ak??m?yorsa ve istek bir If-Range istek ba?l??? tan?mlam?yorsa, sunucu 416 durum kodu d?ndürmelidir. Aral?k bayt aral?klar? kullan?yorsa, bu, istekte belirtilen tüm veri aral?klar?n?n ilk bayt?n?n ge?erli kayna??n uzunlu?unu a?t??? anlam?na gelir. Sunucu, 416 durum koduyla birlikte ge?erli kayna??n uzunlu?unu belirten bir Content-Range varl?k ba?l??? da i?ermelidir. Bu yan?t?n ??erik-Türü olarak multipart/byteranges kullanmas? da yasakt?r. |
| 417 | Expect istek ba?l???nda belirtilen beklenen i?erik sunucu taraf?ndan kar??lanam?yor veya sunucu, Expect i?eri?inin ge?erli rotadaki bir sonraki dü?ümde kar??lanamayaca??na dair a??k kan?tlara sahip bir proxy sunucudur. |
| 421 | Ge?erli istemcinin IP adresinden sunucuya yap?lan ba?lant? say?s?, sunucu taraf?ndan izin verilen maksimum say?y? a??yor. Tipik olarak, buradaki IP adresi, istemcinin sunucudan g?rülen adresini ifade eder (?rne?in, kullan?c?n?n a? ge?idi veya proxy sunucu adresi). Bu durumda, ba?lant? say?m?na birden fazla son kullan?c? dahil olabilir. |
| 422 | Ge?erli istemcinin IP adresinden sunucuya yap?lan ba?lant? say?s?, sunucu taraf?ndan izin verilen maksimum say?y? a??yor. Tipik olarak, buradaki IP adresi, istemcinin sunucudan g?rülen adresini ifade eder (?rne?in, kullan?c?n?n a? ge?idi veya proxy sunucu adresi). Bu durumda, ba?lant? say?s?na birden fazla son kullan?c? dahil olabilir. |
| 422 | ?stek do?ru bi?imlendirilmi?, ancak anlamsal hatalar i?erdi?i i?in yan?tlanamam??t?r. (RFC 4918 WebDAV) 423 Kilitli Ge?erli kaynak kilitli. (RFC 4918 WebDAV) 423 Kilitli |
| 424 | Ge?erli istek, PROPPATCH gibi ?nceki bir istekteki hata nedeniyle ba?ar?s?z oldu. (RFC 4918 WebDAV) |
| 425 | WebDav Geli?mi? Koleksiyonlar tasla??nda tan?mlanm??t?r, ancak WebDAV S?ral? Koleksiyonlar Protokolünde (RFC 3658) g?rünmez. |
| 426 | ?stemciler TLS/1.0'a ge?melidir. (RFC 2817) |
| 449 | Uygun eylem ger?ekle?tirildikten sonra isteklerin yeniden denenmesi gerekti?ini g?stermek i?in Microsoft taraf?ndan geni?letilmi?tir. |
| 500 | Sunucu, iste?i i?lemeyi tamamlamas?n? engelleyen ?ng?rülemeyen bir durumla kar??la?t?. Bu sorun genellikle sunucunun program kodunda bir hata oldu?unda ortaya ??kar. |
| 501 | Sunucu, ge?erli iste?in gerektirdi?i bir ?zelli?i desteklemiyor. Sunucu istenen y?ntemi tan?mad???nda ve herhangi bir kaynak i?in iste?ini destekleyemedi?inde. |
| 502 | A? ge?idi veya proxy olarak ?al??an bir sunucu, bir iste?i yürütmeye ?al??t???nda yukar? ak?? sunucusundan ge?ersiz bir yan?t al?r. |
| 503 | Sunucu, ge?ici sunucu bak?m? veya a??r? yüklenme nedeniyle ?u anda iste?i i?leyememektedir. Bu durum ge?icidir ve bir süre sonra eski haline d?necektir. Bir gecikme beklenebilirse, yan?t gecikmeyi belirtmek i?in bir Retry-After ba?l??? i?erebilir. Bu Retry-After bilgisi verilmezse, istemci bunu 500 yan?t? ile ayn? ?ekilde ele almal?d?r. Not: 503 durum kodunun varl???, sunucunun a??r? yüklenmesi durumunda bunu kullanmas? gerekti?i anlam?na gelmez. Baz? sunucular basit?e istemcinin ba?lant? kurmas?n? engellemek ister. |
| 504 | Bir iste?i ger?ekle?tirmeye ?al??an bir a? ge?idi veya proxy olarak g?rev yapan bir sunucu, yukar? ak?? sunucusundan (HTTP, FTP, LDAP gibi bir URI ile tan?mlanan bir sunucu) veya ikincil bir sunucudan (DNS gibi) zaman?nda yan?t alamaz. Not: Baz? proxy sunucular?, DNS aramas? zaman a??m?na u?rad???nda 400 veya 500 hatas? d?ndürür. |
| 505 | Sunucu, istekte kullan?lan HTTP sürümünü desteklemiyor veya desteklemeyi reddediyor. Bu, sunucunun istemciyle ayn? sürümü kullanamad??? veya kullanmak istemedi?i anlam?na gelir. Yan?t, sürümün neden desteklenmedi?ini ve sunucunun hangi protokolleri destekledi?ini a??klayan bir varl?k i?ermelidir. |
| 506 | ?effaf ??erik Müzakere Protokolü (RFC 2295) taraf?ndan sunucunun dahili bir yanl?? yap?land?rmas?n? temsil edecek ?ekilde geni?letilmi?tir: Talep edilen Müzakere Varyant? kayna??, ?effaf ??erik Müzakeresinde kendisini kullanmak üzere yap?land?r?lm??t?r ve bu nedenle bir müzakere sürecinde uygun bir odak noktas? de?ildir. |
| 507 | Sunucu, iste?i yerine getirmek i?in gerekli i?eri?i depolayam?yor. Bu durum ge?ici olarak kabul edilir.WebDAV(RFC 4918) |
| 509 | Sunucu bant geni?li?i s?n?r?na ula?t?. Bu resmi bir durum kodu de?ildir, ancak hala yayg?n olarak kullan?lmaktad?r. |
| 510 | Kayna?? elde etmek i?in gereken ilke kar??lanmam??t?r. (RFC 2774) |