Çevrimiçi Araçlar
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)
Kayıtlara erişim: