| Http durum kodu | 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 kullanması için Yükseltme mesaj başlığı aracılığıyla istemciyi bilgilendirecektir. Bu yanıtın son boş satırını gönderdikten sonra, sunucu Yükseltme mesaj başlığında tanımlanan protokollere geçecektir. Bu yalnızca yeni bir protokole geçmenin daha faydalı olması durumunda yapılmalıdır. Örneğin, HTTP'nin yeni bir sürümüne geçmek eski bir sürümüne geçmekten daha avantajlıdır veya bu tür özelliklerden yararlanan kaynakları sunmak için gerçek zamanlı ve eşzamanlı bir protokole geçmek daha avantajlıdır. |
| 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ığı veya veri gövdesi bu yanıtla birlikte döndürülecektir. |
| 201 | İstek yerine getirilmiş ve isteğin gerektirdiği şekilde yeni bir kaynak oluşturulmuş ve URI'si Konum başlığıyla birlikte döndürülmüştür. Gerekli kaynak zamanında oluşturulamazsa, '202 Accepted' döndürülmelidir. |
| 202 | Sunucu isteği kabul etmiştir, ancak henüz işleme koymamıştır. Reddedilebileceği gibi, sonunda istek yürütülebilir veya yürütülmeyebilir. Eşzamansız işlemler bağlamında, bu durum kodunu göndermekten daha uygun bir şey yoktur. Bir yanıtı 202 durum koduyla döndürmenin amacı, toplu işlem tamamen tamamlanana kadar istemciyi sunucuya bağlı tutmak zorunda kalmadan sunucunun diğer işlemlerden (günde yalnızca bir kez yürütülen toplu işlem tabanlı bir işlem gibi) gelen istekleri kabul etmesine izin vermektir. İşleme talebini kabul eden ve 202 durum kodunu döndüren bir yanıt, döndürülen varlıkta işlemin mevcut durumunu gösteren bazı bilgilerin yanı sıra kullanıcının işlemin tamamlanıp tamamlanmadığını tahmin edebilmesi için 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, orijinal sürümün bir alt kümesi veya üst kümesi olabilir. Örneğin, kaynak içeren meta veriler orijinal 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 bilgiler döndürebilir. Bu tür başlıklar mevcutsa, istenen değişkenlere karşılık gelmelidir. İstemci bir tarayıcıysa, 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 uygulanmak zorunda olsa da, kullanıcının tarayıcısı herhangi bir belge görünümü değişikliği olmadan 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şlemiş ve hiçbir şey döndürmemiştir. 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 belgeyi aynı anda birden fazla indirme parçasına 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; Content-Type'ı multipart/byteranges olan çok parçalı bir indirme durumunda, her çok parçalı segment, o segmentteki içeriğin kapsamını belirten bir Content-Range alanı içermelidir. 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. date 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 yanıtlardan farklı olabiliyorsa. Expires, Cache-Control ve/veya Vary, değerleri aynı değişkenler için önceki diğer yanıtların değerlerinden farklı olabilirse. Bu yanıt, istek If-Range güçlü önbellek doğrulaması kullanıyorsa diğer varlık başlıklarını İÇERMEMELİDİR ve istek If-Range zayıf önbellek doğrulaması kullanıyorsa diğer varlık başlıklarını İÇERMEMELİDİ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. Aksi takdirde, bu yanıt, döndürülmesi gereken tüm 200 yanıtlarında döndürülmüş olması 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ştirilmesini yasaklamalıdır. Aralık ve İçerik-Aralığı 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 (RFC 2518) 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 kaynak, her biri kendi özel adresi ve tarayıcı odaklı müzakere bilgileri olan bir dizi alternatif dönüş mesajına sahiptir. Kullanıcı veya tarayıcı, yeniden yönlendirme için tercih edilen adresi kendisi seçebilir. 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 böyle bir otomatik seçimin nasıl yapılacağını belirtmez. Sunucunun kendisinin zaten tercih edilen bir dönüş seçeneği varsa, bu dönüşün URI'si Konum'da belirtilmelidir; tarayıcı bu Konum değerini otomatik yeniden yönlendirme için adres olarak kullanabilir. Ayrıca, aksi belirtilmedikçe bu yanıt da önbelleğe alınabilir. |
| 301 | İstenen kaynak kalıcı olarak yeni konuma taşınmıştır ve gelecekte bu kaynağa 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, tarayıcının kullanıcı tarafından onaylanmadıkça 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 bir 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. 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. 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ğa alternatif bir referans değildir. Ayrıca, 303 yanıtının önbelleğe alınması yasaktır. 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 sürümlerinden önceki birçok tarayıcı 303 durumunu düzgün bir şekilde anlamaz. Bu tarayıcılarla etkileşimin dikkate alınması gerekiyorsa, çoğu tarayıcı 302 yanıtını yukarıdaki belirtimin istemcinin 303 yanıtını ele almasını gerektirdiği şekilde ele aldığından, 302 durum kodu işe yarayacaktır. |
| 304 | İstemci izin verilen koşullu bir GET isteği gönderirse ve belgenin içeriği (son ziyaretten bu yana veya isteğin koşullarına göre) değişmemişse, sunucu bu durum kodunu döndürmelidir.304 yanıtlarının mesaj gövdeleri içermesi yasaktır ve bu nedenle her zaman mesaj başlığından sonraki ilk boş satırla biter. Yanıt aşağıdaki başlıkları içermelidir: Sunucunun saati olmadığı sürece Tarih. Saati olmayan bir sunucu bu kurallara uyarsa, 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ı doğru şekilde çalışır.ETag ve/veya Content-Location, aynı istek 200 yanıtı döndürürse.Expires Expires, Cache-Control ve/veya Vary, eğer değer aynı değişken için önceki diğer yanıtlara karşılık gelen değerden farklı olabilirse. Bu yanıt isteği güçlü önbellek doğrulaması kullanıyorsa, bu yanıt diğer varlık başlıklarını içermemelidir; aksi takdirde (örneğin, koşullu bir GET isteği zayıf önbellek doğrulaması kullanıyorsa), bu yanıtın diğer varlık başlıklarını 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 proxy üzerinden erişilmelidir. Konum alanı, belirtilen proxy'nin bulunduğu URI hakkında bilgi verecektir. alıcının kaynağa bu proxy üzerinden erişmek için tekrar tekrar ayrı bir istek göndermesi gerekecektir. 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 kaynak artık geçici olarak farklı bir URI'den talebe yanıt vermektedir. Bu tür yönlendirmeler 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, kullanıcı tarafından onaylanmadıkça tarayıcı otomatik yeniden yönlendirmeyi yasaklar, çünkü isteğin koşulları değişebilir. |
| 400 | 1. Anlamsal bir hata var ve mevcut istek sunucu tarafından anlaşılamıyor. Değiştirilmediği sürece, istemci bu isteği tekrar göndermemelidir. 2. İstek 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 başlığı bilgilerini içeren bir isteği tekrar tekrar 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 kez kimlik doğrulama girişiminde bulunmuşsa, bu varlık bilgileri ilgili tanılama bilgilerini içerebileceğinden, tarayıcı kullanıcıya yanıtta yer alan varlık bilgilerini sunmalıdır. RFC 2617'ye bakın. |
| 402 | Bu durum kodu gelecekteki olası gereksinimler için ayrılmıştır. |
| 403 | Sunucu isteği anlamış ancak yürütmeyi reddediyor. 401 yanıtının aksine, kimlik doğrulama herhangi bir yardım sağlamaz ve bu istek yeniden gönderilmemelidir. Bu bir HEAD isteği değilse ve sunucu isteğin neden gerçekleştirilemeyeceğini açıkça belirtmek istiyorsa, reddetme nedeni varlık içinde açıklanmalıdır. Elbette sunucu istemciye herhangi bir bilgi vermek 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, kullanıcıya 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 yanıt bulunmadığı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öntemlerinin sunucu üzerindeki kaynağa yazdığı göz önüne alındığında, ç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 olmadığı sürece, yanıt, kullanıcının veya tarayıcının en uygun olanı seçebileceği varlık özelliklerinin ve adreslerinin bir listesini içeren bir varlık döndürmelidir. Varlığın biçimi Content-Type başlığında tanımlanan ortam türüne göre belirlenir. Tarayıcılar biçime ve kendi yeteneklerine göre kendi en iyi seçimlerini yapabilirler. Ancak, spesifikasyon bu tür otomatik seçimler yapmak için herhangi bir kriter tanımlamaz. |
| 407 | İstemcinin proxy sunucusunda kimlik doğrulaması YAPMASI GEREKMESİ dışında 401 yanıtına benzer. Proxy sunucusu kimlik sorgulaması için bir Proxy-Kimlik Doğrulama döndürmelidir. İstemci, kimlik doğrulama için bir Proxy-Yetkilendirme 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 istek göndermeyi 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, belirli bir kaynağı değiştirmek için gönderilen bir PUT'a eklenen sürüm bilgisi önceki (üçüncü taraf) bir istekle çakışırsa, sunucu kullanıcıya isteğin tamamlanamadığını bildiren bir 409 hatası döndürmelidir. Bu durumda, yanıt varlığının çakışan iki sürüm arasındaki farkların bir karşılaştırmasını içermesi muhtemeldir, böylece kullanıcı birleştirme işleminden sonra yeni 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 bu 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 amacı, öncelikle kullanıcıya kaynağın artık mevcut olmadığını ve sunucu sahibinin bu kaynağa olan tüm uzak bağlantıların da kaldırılmasını istediğini bildirerek web yöneticisine sitenin bakımında yardımcı olmaktır. Bu tür olaylar zaman sınırlı, katma değerli hizmetlerde yaygındır. Benzer şekilde 410 yanıtı, istemcilere mevcut sunucu sitesindeki bir kişiye ait olan bir kaynağın artık mevcut olmadığını bildirmek için kullanılır. Elbette, kalıcı olarak kullanılamayan tüm kaynakların '410 Gitti' olarak işaretlenmesi gerekip gerekmediği ve bu işaretlemenin ne kadar süreyle sürdürülmesi 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 tekrar gönderebilir. |
| 412 | Sunucu, isteğin başlık alanında verildiğini doğrularken bir veya daha fazla önkoşulu karşılayamadı. Bu durum kodu, istemcinin bir kaynak elde ederken isteğin meta mesajında (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ı önler. |
| 413 | Sunucu mevcut isteği işlemeyi reddeder, çünkü sunucunun işlemek istediğinden veya işleyebileceğinden daha büyük boyutta varlık verileri gönderir. Bu durumda sunucu, istemcinin bu isteği göndermeye devam etmesini önlemek için bağlantıyı kapatabilir. Bu durum geçiciyse, sunucu istemciye ne kadar süre sonra yeniden deneyebileceğini bildirmek için bir Retry-After yanıt başlığı döndürmelidir. |
| 414 | İsteğin URI'sinin uzunluğu sunucunun yorumlayabileceği uzunluğu aşıyor, bu nedenle sunucu isteği sunmayı reddediyor. Bu nadir görülen bir durumdur ve genellikle POST yöntemini kullanması gereken bir form gönderimi GET yöntemine dönüştüğünde uzun bir Sorgu Dizesi ile sonuçlanır. Yönlendirme URI "kara delikleri", örneğin her yönlendirmede 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, bir isteğin URI'sini okumak veya değiştirmek için sabit uzunlukta bir arabellek kullanır ve bir GET'den sonraki parametreler belirli bir değeri aştığında, arabellek taşması meydana gelebilir ve bu da 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 | O anda istenen yöntem ve istenen kaynak için, istekte gönderilen varlık sunucuda desteklenen bir biçimde değildir, bu nedenle 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 örtüşmüyorsa ve istekte If-Range istek başlığı tanımlanmamışsa, sunucu bir 416 durum kodu döndürmelidir. Aralık bayt aralıkları kullanıyorsa, istekte belirtilen tüm veri aralıklarının ilk bayt konumu geçerli kaynağın uzunluğunu aşıyorsa bu durum söz konusudur. 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 bu 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 bulunduğu 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ı birden fazla son kullanıcıyı içerebilir. |
| 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ı birden fazla son kullanıcıyı içerebilir. |
| 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) |
| 424 | Geçerli istek, PROPPATCH gibi önceki bir istekte meydana gelen bir 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ğin işlenmesini tamamlamasını engelleyen beklenmedik bir durumla karşılaştı. Bu sorun genellikle sunucunun program kodunda bir hata olduğunda ortaya çıkar. |
| 501 | Sunucu, geçerli istek için gerekli olan belirli bir özelliği desteklemiyordur. Sunucu istenen yöntemi tanıyamadığı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şleyemiyor. 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 sadece istemcinin bağlantı kurmasını engellemek ister. |
| 504 | Bir isteği gerçekleştirmeye çalışan bir ağ geçidi veya proxy olarak çalışan bir sunucu, bir 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: istenen Müzakere Varyantı kaynağı, şeffaf iç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 tamamlamak 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) |