Bir proxy şirketi neden durum kodları hakkında yazıyor: Biz Geonode’uz ve kullanıcılar API trafiğini bizim üzerimizden yönlendiriyor; bu nedenle, belirli bir hatanın “proxy kaynaklı” olup olmadığı soruluyor. 415 hatası için cevap, esasen her zaman “hayır”dır. 415 hatası, kaynak sunucudan gelir ve sizin oluşturduğunuz istekle ilgili bir durumu belirtir. Bir aracı, çok sınırlı durumlarda bu hatayı üretebilir — gövdeleri inceleyen bir filtreleme proxy'si, kendi içerik kuralları olan bir ağ geçidi gibi — ancak bu durum nadirdir ve yanıt başlıklarında belirtilir. Bir proxy üzerinden 415 hatası alıyorsanız, proxy'yi kaldırın; neredeyse kesin olarak aynı 415 hatasını doğrudan alacaksınız. İsteği düzeltin. Gerçekten bir proxy'yi işaret eden tek durum kodu 407'dir ve adından da anlaşılacağı gibi.
Şimdi, asıl hataya gelelim.
Spesifikasyonda Ne Yazıyor?
RFC 9110, Bölüm 15.5.16’da bu durum kesin olarak tanımlanmaktadır:
415 (Desteklenmeyen Ortam Türü) durum kodu, içeriğin hedef kaynakta bu yöntem tarafından desteklenmeyen bir formatta olması nedeniyle kaynak sunucunun isteği işlemeyi reddettiğini gösterir.
Bu cümlenin üç kısmı doğrudur.
"İçerik" — istek gövdesi; URL, sorgu dizesi veya yanıt değil. İsteğinizin gövdesi yoksa, 415 hatası olağandışıdır ve başka bir sorunun olduğunu gösterir.
"Bu yöntem tarafından desteklenmiyor" — destek, yönteme göredir. Bir kaynak, POST yönteminde application/json formatını kabul edip PATCH yönteminde reddedebilir; bu, aynı uç noktanın farklı fiiller altında farklı davranması durumunda gerçekten yaygın bir kafa karışıklığı kaynağıdır.
"Hedef kaynakta" — ve kaynak bazında. Bir API'deki bir uç noktanın bir formatı kabul etmesi, diğer uç noktalar hakkında hiçbir şey ifade etmez.
Spesifikasyon daha sonra nedenleri sıralar:
Format sorunu, isteğin belirtilen Content-Type veya Content-Encoding değerlerinden kaynaklanabilir ya da verilerin doğrudan incelenmesi sonucunda ortaya çıkabilir.
Bu son cümle önemlidir ve genellikle göz ardı edilir. Bir sunucunun, yalnızca başlıkları okuduktan sonra değil, baytları inceledikten sonra da 415 yanıtını döndürmesine izin verilir. Content-Type: application/json bildirip JSON olmayan bir şey göndermek, 400 yerine meşru bir şekilde 415 yanıtını doğurabilir.
RFC ayrıca sunucunun size ne bildirmesi gerektiğini de belirtir. Sorun içerik kodlamasındaysa, Accept-Encoding yanıt başlığının "hangi içerik kodlamalarının (varsa) kabul edileceğini belirtmek için kullanılması gerektiği" belirtilir. Sorun medya türündeyse, Accept "hangi medya türlerinin kabul edileceğini belirtmek için kullanılabilir". Uygulamada, MDN belgeleri sunucuların yöntemlere özgü durumlarda genellikle Accept-Post ve Accept-Patch kullandığını belirtir; bu da daha da kullanışlıdır.
Yanıt başlıklarını okuyun. Sunucular sıklıkla size cevabı verir, ancak istemciler bunu genellikle göz ardı eder.
Buna Neden Olan Altı Şey
Bunları ne sıklıkla gördüğümüzün kabaca sırasına göre.
1. Content-Type'in tamamen eksik olması. Bir gövde gönderiyorsunuz ancak formatını hiç belirtmiyorsunuz. Birçok çerçeve bunu tahmin edemez. MDN'nin örneği tam da budur: JSON gövdeli, Content-Length içeren ve Content-Type belirtilmeyen bir POST isteği; buna 415 ve Accept-Post: application/json; charset=UTF-8 ile yanıt verilir.
2. Yanlış Content-Type. Klasik bir hata, application/x-www-form-urlencoded olarak bildirirken JSON göndermektir; bu genellikle HTTP istemcisinin varsayılan olarak form kodlamasını kullanması ve sizin JSON dizesini değiştirmeden göndermenizden kaynaklanır. Gövde doğrudur; etiket yanlıştır.
3. Yakın ama yanlış medya türü. application/json yerine text/json. Sunucunun text/xml istediği yerde application/xml. application/vnd.api+json gibi satıcı türleri, oysa siz düz application/json gönderdiniz. Katı sunucular tam eşleştirme yapar ve hoşgörülü davranmazlar.
4. Karakter kümesi sorunları. MDN en net örneği veriyor: sunucunun UTF-8 gerektirdiği yerde UTF8 göndermek. Kayıtlı adda tire isteğe bağlı değildir ve katı parametre doğrulaması yapan bir sunucunun bunu reddetme hakkı vardır.
5. Sunucunun desteklemediğContent-Encoding'leri. İstek gövdesini gzip ile sıkıştırıp, yalnızca kimlik kodlamasını destekleyen bir sunucuya karşı Content-Encoding: gzip ayarını yaparsınız. RFC bu durumu özellikle öngörür ve düzgün çalışan bir sunucu, neye ihtiyaç duyduğunu belirten Accept-Encoding yanıtını döndürmelidir.
6. Gövde, beyan edilen türle eşleşmiyor. Doğru başlık, yanlış baytlar — genellikle bir serileştirme hatası, boş bir dize üreten bir şablon veya yığın içinde bir yerde çift kodlanmış bir gövde. Bu, "verileri doğrudan inceleme" maddesinin işleyişidir.
415, 406, 400 ve 422 Karşılaştırması
Bu, kafa karışıklığına yol açan bir tablo; oysa teknik şartnamede bunlar net bir şekilde birbirinden ayrılmıştır.
| Kod | Anlamı | Yön | Düzeltme yöntemi |
|---|
| 415 | Gönderdiğiniz biçim desteklenmiyor | İstek gövdesi | Content-Type veya Content-Encoding |
| 406 | Kabul ettiğiniz hiçbir temsil mevcut değil | Yanıt | Accept başlığı |
| 400 | İstek hatalı biçimlendirilmiş | Tüm istek | Sözdizimi veya çerçeveleme |
| 422 | Biçim anlaşıldı, içerik işlenemez | İstek gövdesi | Verinin kendisi |
| 413 | Gövde çok büyük | İstek gövdesi | Yük boyutu |
415 ile 406 arasındaki fark, yön sorunudur ve bir kez açıklandıktan sonra anlaşılması en kolay olanıdır. 415, gönderdiğiniz şeyle ilgilidir. 406 ise almak istediğiniz şeyle ilgilidir — RFC 9110, bunu “alınan proaktif müzakere başlık alanlarına göre, kullanıcı aracısı tarafından kabul edilebilir bir güncel temsiline sahip olmayan kaynak” olarak tanımlar. 406 hatası alıyorsanız, gövdeye değil, Accept başlığına bakın.
415 ile 400 arasındaki fark. RFC 9110, 400 kodunu, sunucunun "istemci hatası olarak algılanan bir durum nedeniyle (örneğin, hatalı istek sözdizimi, geçersiz istek mesajı çerçevesi veya yanıltıcı istek yönlendirmesi)" isteği işleme koymaması olarak tanımlar. 400 hatası yapısaldır — isteğin kendisi hatalıdır. 415 ise, gövdesi sunucunun kabul etmeyeceği bir formatta olan, ancak biçimsel olarak doğru bir istektir. Uygulamada birçok sunucu, 415'in daha doğru olacağı durumlarda 400 yanıtı verir; bunu kontrol edemezsiniz, bu nedenle gövdesi olan bir istekte 400 kodunu, gizli bir 415 olarak değerlendirin.
415 ile 422 arasındaki fark, RFC'nin en açık şekilde ortaya koyduğu ayrımdır. Bölüm 15.5.21’de, 422 kodunun “sunucunun istek içeriğinin içerik türünü anladığı (dolayısıyla 415 (Desteklenmeyen Ortam Türü) durum kodu uygun değildir) ve istek içeriğinin sözdiziminin doğru olduğu, ancak içerdiği talimatları işleyemediği” anlamına geldiği belirtilmektedir.
Dolayısıyla sıralama şöyledir: 415, sarmalayıcının yanlış olduğu anlamına gelir; 422 ise sarmalayıcının doğru, içeriğin yanlış olduğu anlamına gelir. Gerekli bir alanın eksik olduğu, biçim açısından doğru bir JSON, 422 koduna karşılık gelir. Form verisi olarak etiketlenmiş aynı JSON ise 415 koduna karşılık gelir.
İki Dakikadan Az Sürede Teşhis Etme
Neredeyse tüm vakaları çözen sabit bir adım dizisi.
Birinci adım: Yanıt başlıklarını okuyun. Durum satırını değil, başlıkları.
curl -i -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
Yanıtta Accept, Accept-Post, Accept-Patch veya Accept-Encoding ifadesini arayın. Bunlardan herhangi biri varsa, bu sunucunun ne istediğinin doğrudan bir ifadesidir ve işiniz bitmiştir.
İkinci adım: Gerçekte ne gönderdiğinizi doğrulayın. Göndermek istediğiniz şeyi değil, ağ üzerinden gönderilen şeyi. İstemci kütüphaneleri başlıkları ekler, üzerine yazar ve yeniden biçimlendirir; kodda ayarladığınız başlık her zaman iletilen başlık olmayabilir.
curl -v -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}' 2>&1 | grep '^>'
> satırları, gerçek isteğinizdir. 415 hatalarının şaşırtıcı bir kısmı tam da burada çözülür; çünkü özenle ayarladığınız Content-Type değerinin varsayılan bir değerle üzerine yazıldığı ortaya çıkar.
Üçüncü adım: yöntemi kontrol edin. Aynı uç nokta, POST yönteminde bir türü kabul ederken PATCH yönteminde reddedebilir. Aynı gövdeyi farklı bir fiil altında deneyin ve davranışın değişip değişmediğine bakın.
Dördüncü adım: tam tür dizesini kontrol edin. Belgelerdeki metinle karakter karakter karşılaştırın. application/json ile text/json. UTF-8 ile UTF8. Satıcı sonekleri. Bu işlem zahmetlidir, ancak cevap genellikle burada yatmaktadır.
Beşinci adım: söz konusu uç nokta için belgeleri okuyun. API’ler içsel olarak tek tip değildir. Aksi takdirde JSON API olan bir sistemde multipart/form-data formatını isteyen bir dosya yükleme uç noktası tamamen normaldir.
İstemci Tarafında Düzeltme
Yaygın istemcilerde sık karşılaşılan durumlar.
curl. -d, aksi belirtilmedikçe application/x-www-form-urlencoded anlamına gelir. Bu, komut satırından 415 hatasının en yaygın tek nedenidir:
curl -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
JavaScript fetch. Bir dize gövdesi aktarılması durumunda Content-Type değeri hiç ayarlanmaz:
await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "test" }),
});
Bilmeniz gereken bir istisna: FormData kullanırken, Content-Type değerini kendiniz ayarlamayın. Bu değer, multipart sınırını içerdiği için tarayıcı tarafından oluşturulmalıdır; bu değeri geçersiz kılmak, genellikle 415 hatası olarak ortaya çıkan hatalı bir istek oluşturur.
Python requests. data= yerine json= kullanın; başlık sizin için otomatik olarak ayarlanır:
requests.post(url, json={"name": "test"}) # application/json
requests.post(url, data={"name": "test"}) # form-encoded
Axios. Düz nesneler için application/json değerini, dizeler için ise başka bir değer ayarlar; bu durum sık sık şaşırtıcı sonuçlara yol açar. Yükünüzü zaten serileştirmişseniz, başlığı açıkça ayarlayın. Burada istemciler arasındaki davranış farklılıkları, tam da axios vs fetch başlıklı yazımızda ele aldığımız türden konulardır.
Genel bir kural: Bir istemci JSON'a özgü bir parametre sunuyorsa, elle serileştirip varsayılan başlığın doğru olmasını ummak yerine bu parametreyi kullanın.
Sunucu Tarafında Doğru Şekilde Geri Dönüş Yapma
Eğer karşı taraftaysanız, API’nizle çalışmayı önemli ölçüde kolaylaştıracak birkaç nokta vardır.
415 koduyla birlikte bir Accept-Post veya Accept-Patch başlığı gönderin. RFC, Accept veya Accept-Encoding kullanılmasını öngörür; yönteme özgü varyantlar daha kesindir ve MDN bunları tam da bu kullanım için belgelemektedir. Bu tek başlık, bir hata ayıklama oturumunu bir bakışta anlaşılır hale getirir.
Okunabilir bir gövde ekleyin. Gövdesiz bir durum kodu, istemcinin tahminde bulunmasına neden olur. Ne aldığınızı ve ne beklediğinizi belirtin.
415 ile 422 kodlarını doğru şekilde ayırt edin. İçerik türünü anladıysanız ve gövdeyi ayrıştırdıysanız ancak doğrulama başarısız olduysa, bu bir 422 hatasıdır. Doğrulama hataları için 415 kodunu döndürmek, başlıkları sorunsuz olan kullanıcıları başlıklarını kontrol etmeye yönlendirir ve bu, API tasarımında yaygın ve maliyetli bir hatadır.
Güvenli olduğu durumlarda parametreler konusunda esnek olun. application/json'yi kabul ederken application/json; charset=utf-8'yi reddetmek teknik olarak savunulabilir, ancak pratikte hiçbir faydası yoktur. Medya türünü doğru şekilde ayrıştırın ve önemsemediğiniz parametreleri göz ardı edin.
415 kodunu genel bir reddetme olarak kullanmayın. Bu kodun belirli bir anlamı vardır. Bu kodu aşırı yüklemek, API'nizin kullanımını zorlaştırır ve istemci tarafındaki yeniden deneme mantığını bozar.
415 Hatası Aslında 415 Değilse
Durum kodunun yanıltıcı olduğu durumlar.
Bir ağ geçidi veya WAF, isteği reddetti. Bazı güvenlik katmanları, gerçek içerik türünden bağımsız olarak şüpheli gördükleri gövdelere 415 kodunu döndürür. Bunun ipucu genellikle, uygulamadan gelmiş gibi görünmeyen bir yanıt gövdesi veya bir aracıyı tanımlayan başlıklardır.
Kodunuz çalışmadan önce bir çerçeve varsayılanı tetiklendi. Birçok web çerçevesi, ara yazılımda bilinmeyen içerik türlerini reddeder. İşleyiciniz hiçbir zaman çalıştırılmadığından, uygulama mantığınızda düzeltmeyle ilgili hiçbir şey yoktur.
Bir yük dengeleyici veya CDN bir başlığı kaldırdı. Nadir görülür ancak gerçektir. İstek doğrudan gönderildiğinde çalışıyor ancak altyapı üzerinden gönderildiğinde başarısız oluyorsa, uygulamanın değiştiğini varsaymadan önce her iki uçtaki başlıkları karşılaştırın.
Uç nokta mevcut değil. Bazı sunucular, yönlendirme çözülmeden önce içerik türü müzakeresi gerçekleştiği için, POST isteğinde eşleşmeyen bir rotaya 404 yerine 415 yanıtı verir. URL'yi kontrol edin.
HTTP yöntemi geçersiz kılma işlemi hatalı sonuçlandı. Çerçeveniz, bir başlık veya sorgu parametresi aracılığıyla yöntemin geçersiz kılınmasını destekliyorsa, etkin yöntem gönderdiğiniz yöntem olmayabilir ve içerik türü desteği yönteme özeldir.
Bu durumların her birinde, çözüm yükünüzün daha üst aşamalarında yatmaktadır. Genel kural şudur: İstek açıkça doğruysa ve 415 hatası devam ediyorsa, gövdeyi düzenlemeyi bırakın ve yoldaki hangi bileşenin bu yanıtı ürettiğini bulmaya çalışın.
Sık Sorulan Sorular
415 Desteklenmeyen Ortam Türü hatası ne anlama gelir?
İstek gövdesinin biçimi, söz konusu kaynakta o yöntem için desteklenmediği için sunucu isteği reddetti. RFC 9110, bu durumu Content-Type başlığına, Content-Encoding başlığına veya sunucunun gövdeyi doğrudan incelemesine bağlamaktadır. Bu, verilerin doğruluğuyla değil, gönderdiğiniz içeriğin biçimiyle ilgilidir.
415 hatasını nasıl düzeltebilirim?
Öncelikle yanıt başlıklarını kontrol edin — sunucular genellikle tam olarak ne istediklerini belirten Accept, Accept-Post veya Accept-Encoding başlıklarını döndürür. Ardından, kütüphaneler başlıkları geçersiz kıldığından, istemcinizin gerçekte ne ilettiğini doğrulayın. En yaygın tek çözüm, içinde Content-Type: application/json bulunmayan bir isteğe bunu eklemektir.
415 ile 400 arasındaki fark nedir?
400, isteğin hatalı biçimlendirildiğini gösterir — sözdizimi veya çerçeveleme hatası. 415 ise isteğin doğru biçimlendirilmiş olduğunu, ancak gövdenin desteklenmeyen bir formatta olduğunu gösterir. Uygulamada sunucular, 415 kodunun daha doğru olacağı durumlarda sıklıkla 400 kodunu döndürür; bu nedenle, gövdesi olan bir istekte 400 kodu alınırsa, olası bir içerik türü sorunu olarak araştırılmaya değer.
415 ile 422 arasındaki fark nedir?
RFC 9110 bu ayrımı açıkça belirtir: 422, sunucunun içerik türünü anladığını ve sözdiziminin doğru olduğunu, ancak talimatları işleyemediğini ifade eder. Dolayısıyla 415, dış yapının yanlış olması; 422 ise içeriğin yanlış olması anlamına gelir. Gerekli bir alanın eksik olduğu geçerli bir JSON, 422 hatasıdır.
Dosya yüklerken neden 415 hatası alıyorum?
Genellikle bunun nedeni, çok parçalı bir istekte Content-Type başlığının manuel olarak ayarlanmış olmasıdır. Bu başlık, çok parçalı sınırını içerdiğinden tarayıcı veya istemci tarafından kendiliğinden oluşturulmalıdır. Bunu kendiniz ayarladığınızda sınır kaldırılır ve sunucunun çözümleyemediği bir istek oluşur.
Bir proxy 415 hatasına neden olabilir mi?
Nadiren. 415 hatası, kaynak sunucudan gelir ve isteğinizin gövdesini tanımlar. İçeriği inceleyen bir filtreleme proxy'si veya ağ geçidi bu hatayı oluşturabilir, ancak proxy'lere özgü genel durum kodu 407'dir ve adından da anlaşılacağı gibi bu durumu belirtir. Proxy olmadan test edin — 415 hatası devam ederse, sorunun proxy ile ilgisi yoktur.
415 hatası, JSON'umun geçersiz olduğu anlamına mı gelir?
İlle de öyle değildir. Sunucu içerik türünü reddettiyse, JSON'unuz hiç incelenmemiştir. Sunucu doğru türü bildirmiş ve ardından gövdenin aslında o formatta olmadığını tespit etmişse, o zaman evet — RFC, "verileri doğrudan inceledikten" sonra reddetmeye izin verir. Önce başlık sorununu kontrol edin; bu durum çok daha yaygındır.
415 hatası aldıktan sonra yeniden denemeli miyim?
Hayır. Bu bir istemci hatasıdır ve aynı istek aynı sonucu verecektir. Yeniden denemek istekleri boşa harcar ve istek sıklığı sınırlamasına tabiyseniz durumu daha da kötüleştirebilir. İçerik türünü düzeltin ve tek seferde gönderin.
Sonuç
415 kodunun dar ve kesin bir anlamı vardır: Verilerinizin etrafındaki sarmalayıcı, bu uç noktanın bu yöntem için kabul ettiği türden değildir. Bu, verilerinizin geçersiz olmasıyla ilgili değildir — bu durum için 422 kodu kullanılır — ve ne almayı talep ettiğinizle de ilgisi yoktur — bu durum için 406 kodu kullanılır.
Anlamı dar olduğu için teşhis de kısadır. Yanıt başlıklarını okuyun; çünkü düzgün çalışan bir sunucu, kabul edilebilir türleri Accept, Accept-Post veya Accept-Encoding başlıklarında belirtir. Ardından, istemcinize ne talimat verdiğinizden ziyade, istemcinizin ağa gerçekte ne gönderdiğini doğrulayın; çünkü varsayılan ayarlar ve ara yazılımlar, sizin ayarladığınız başlığı rutin olarak geçersiz kılar. Bu iki adım arasında, gövdeye hiç dokunmadan çoğu sorunu çözebileceksiniz.
Eğer istek kusursuz görünüyorsa ve 415 hatası devam ediyorsa, yanıt muhtemelen düşündüğünüz uygulamadan gelmiyor demektir. Ağ geçitleri, çerçeve ara yazılımları ve eşleşmeyen rotaların tümü, yükünüzle hiçbir ilgisi olmayan 415 hataları üretir — bu noktada asıl önemli olan soru, neyi değiştireceğiniz değil, yol üzerindeki hangi bileşenin yanıt verdiğidir.
