HTTP "415 Unsupported Media Type" Hatası Neden Alınır?

415 unsupported media type hatası neden alınır? Sunucu, isteğin gövdesinde gönderilen veri biçimini veya bu biçimi bildiren Content-Type değerini desteklemediğinde HTTP 415 yanıtı döndürebilir. Sorun, istemcinin gönderdiği medya türü ile ilgili endpoint'in kabul ettiği veri biçiminin uyuşmamasından kaynaklanır.

Örneğin JSON içeriği text/plain olarak etiketlenirse sunucu bu gövdeyi JSON olarak ayrıştıramayabilir. Bununla birlikte 415, gövdenin sözdiziminin doğru ya da yanlış olduğunu tek başına göstermez; başlık seçimi ile içerik doğrulaması ayrı kontrollerdir.

HTTP "415 Unsupported Media Type" Hatası Neden Alınır?

HTTP 415 hatası, sunucunun istek gövdesini belirtilen medya türüyle işleyemediği durumlarda görülür. Content-Type başlığı eksik, hatalı yazılmış veya endpoint'in desteklemediği bir değer taşıyor olabilir. Örneğin endpoint JSON beklerken application/x-www-form-urlencoded gönderilmesi ya da JSON gövdesinin text/plain olarak işaretlenmesi bu duruma yol açabilir.

Burada iki noktayı ayrı değerlendirmek gerekir. İlk kontrol, gövdenin hangi biçimde gönderildiği ve başlıkta bunun doğru bildirilip bildirilmediğidir. İkinci kontrol ise gövdenin gerçekten o biçime uyup uymadığıdır. application/json yazan bir istek, JSON olmayan bir metin taşıyorsa medya türü doğru görünse bile ayrıştırma sırasında başka bir hata oluşabilir. Bu nedenle 415 incelemesinde istek başlıklarını ve ham gövdeyi birlikte kontrol etmek gerekir.

Content-Type ile Accept arasındaki fark nedir?

Content-Type, gönderilen istek gövdesinin medya türünü belirtir. Accept ise sunucunun yanıtı hangi medya türlerinde döndürmesini istediğini veya kabul edebileceğini bildirir. Kısaca, ilki “gönderdiğim veri nedir”, ikincisi “yanıtta hangi biçimi kabul edebilirim” sorusuyla ilgilidir.

Aynı gövde metnini farklı bir medya türüyle göndermek, yalnızca başlığı değiştirmek anlamına gelmez. Örneğin {"name":"Ada"} gövdesi JSON biçimindedir. Bu gövde application/x-www-form-urlencoded olarak işaretlenirse sunucu, içeriği name=Ada biçimindeki bir form verisi gibi bekleyebilir ve isteği reddedebilir.

İstek akışında istemci, gövdeyi hangi biçimde gönderdiğini Content-Type ile bildirir. Sunucudan beklediği yanıt biçimini ayrıca Accept ile belirtir. Bu yüzden Accept: application/json yazılması, gönderilen gövdenin JSON olduğu anlamına gelmez. Aynı şekilde Content-Type: application/json başlığı da sunucunun mutlaka JSON yanıt döndüreceği anlamına gelmez.

POST /api/ogrenciler HTTP/1.1
Host: example.test
Content-Type: application/json
Accept: application/json

{"name":"Ada"}

Bu örnekte gövde JSON olarak gönderilir ve JSON yanıt tercih edilir. Sunucu JSON'u destekliyorsa beklenen akış, gövdeyi JSON olarak ayrıştırması ve uygun bir yanıt üretmesidir. Gerçek durum kodu endpoint'in işlem sonucuna bağlıdır; başlıkların doğru olması, gövdenin de belirtilen biçime uygun olmasını gerektirir.

JSON gönderirken 415 hatasına yol açan yaygın nedenler

JSON gönderirken alınan 415 hatası genellikle istek gövdesinin biçimi ile Content-Type başlığının veya endpoint sözleşmesinin uyuşmamasından kaynaklanır. Content-Type gönderilen verinin biçimini bildirir. Accept ise sunucudan beklenen yanıt biçimini belirtir. Bu nedenle geçerli JSON üretmek tek başına yeterli olmayabilir.

Eksik veya yanlış Content-Type

JSON gövdesi gönderiliyorsa çoğu endpoint bu gövdenin application/json olarak etiketlenmesini bekler. JSON metnini application/x-www-form-urlencoded veya text/plain olarak göndermek, gövde içerik olarak JSON olsa bile sunucunun isteği reddetmesine yol açabilir. application/x-www-form-urlencoded anahtar ve değer çiftleri, multipart/form-data ise ayrı form parçaları için kullanılır. Bu başlıklar gövdeyi dönüştürmez, yalnızca gövdenin nasıl yorumlanacağını bildirir.

Geçersiz JSON gövdesi

Content-Type: application/json kullanılması gövdeyi otomatik olarak geçerli JSON yapmaz. Tek tırnak kullanımı, eksik çift tırnak, fazladan virgül veya kapatılmamış süslü parantez gibi sözdizimi hataları ayrıca denetlenmelidir. Medya türü kabul edildiği hâlde sunucu gövdeyi ayrıştıramıyorsa sorun çoğunlukla 400 kapsamındadır. Geçersiz gövde her durumda otomatik olarak 415 anlamına gelmez.

Endpoint sözleşmesiyle uyuşmayan medya türü

JSON sözdizimi doğru ve başlık eksiksiz olsa bile endpoint farklı bir medya türü bekliyor olabilir. Örneğin sözleşme form verisi veya çok parçalı form bekliyorsa, application/json ile gönderilen geçerli bir gövde yine 415 üretebilir.

fetch("/api/ogrenciler", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Accept": "application/json"
  },
  body: JSON.stringify({
    ad: "Deniz",
    ders: "Java"
  })
});

Bu örnekte JSON.stringify nesneyi JSON metnine dönüştürür. Endpoint JSON kabul ediyorsa sunucu gövdeyi bu biçimde yorumlar. Endpoint başka bir medya türü bekliyorsa gövde geçerli olsa bile başlık ve sözleşme uyumsuzluğu giderilmelidir.

400, 406 ve 415 hataları nasıl ayırt edilir?

Bu üç durum kodunu ayırırken önce hangi isteğe ait biçimin sorunlu olduğunu belirle. Gönderilen gövde, gövdenin medya türü ve beklenen yanıt biçimi birbirinden ayrı incelenmelidir.

Kısaca, gönderilen verinin türü kabul edilmiyorsa 415, tür kabul edildiği hâlde gövde okunamıyorsa 400, sunucunun yanıt biçimi Accept başlığıyla uyuşmuyorsa 406 üzerinde durulur.

415 hatası için adım adım kontrol sırası

415 hatasını ayıklarken kontrolleri rastgele yapmak yerine istek sözleşmesinden yanıt tercihine doğru ilerle. Her adımda elde ettiğin bulgu, bir sonraki kararın yönünü belirler.

1. Endpoint sözleşmesinin kabul ettiği medya türünü ve gövde biçimini kontrol et.
   • Kontrol edilecek alan: Endpoint dokümanındaki HTTP yöntemi, kabul edilen medya türleri ve beklenen gövde yapısı.
   • Beklenen bulgu: Endpoint'in JSON, form verisi veya başka bir gövde biçimi beklediği açıkça anlaşılmalı.
   • Sonraki karar: Göndereceğin medya türü kabul edilenler arasında değilse 415 dalına geç. Eşleşiyorsa ikinci adıma ilerle.
2. Gerçek gövdeyle Content-Type değerini karşılaştır.
   • Kontrol edilecek alan: İsteğin ham gövdesi ve Content-Type başlığı.
   • Beklenen bulgu: JSON gövde için application/json, URL kodlu form verisi için application/x-www-form-urlencoded, dosya veya parçalı form verisi için uygun multipart türü kullanılmalı.
   • Sonraki karar: Gövde ile başlık farklı medya türlerini gösteriyorsa 415 olasılığına odaklan. Eşleşiyorsa üçüncü adıma geç.
3. Gövdenin sözdizimini ve sözleşmeye uygun biçimini doğrula.
   • Kontrol edilecek alan: JSON ayrıştırılabiliyor mu, zorunlu alanlar bulunuyor mu, veri türleri ve iç içe yapı endpoint'in beklediği biçimde mi?
   • Beklenen bulgu: Medya türü kabul edilmiş, gövde ise hem sözdizimi hem de beklenen alan yapısı bakımından geçerli olmalı.
   • Sonraki karar: Medya türü doğru olduğu hâlde gövde bozuksa 400 dalını incele. Gövde de uygunsa dördüncü adıma geç.
4. Yanıt için Accept başlığını incele.
   • Kontrol edilecek alan: İstemcinin Accept ile istediği yanıt türü ve sunucunun üretebildiği yanıt türleri.
   • Beklenen bulgu: Sunucunun döndürebileceği en az bir yanıt biçimi, istemcinin kabul ettiği türlerle eşleşmeli.
   • Sonraki karar: İstek gövdesi uygun, fakat yanıt tercihi uyumsuzsa 406 dalına geç. Eşleşme varsa 415 nedenini başka bir başlıkta arama.

Yanlış Content-Type içeren POST isteği nasıl düzeltilir?

/api/profile endpoint'inin JSON kabul ettiğini varsayalım. Aşağıdaki blokta ilk istek hatalı, ikinci istek düzeltilmiş varyanttır. Son ileti, örnek sözleşmeye bağlı temsilî yanıttır.

POST /api/profile HTTP/1.1
Host: example.test
Content-Type: text/plain
Content-Length: 14

{"name":"Ada"}

POST /api/profile HTTP/1.1
Host: example.test
Content-Type: application/json
Accept: application/json
Content-Length: 14

{"name":"Ada"}

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 11

{"ok":true}

İlk istekte gövde JSON biçiminde görünse de Content-Type: text/plain başlığı sunucuya farklı bir medya türü bildirir. Endpoint yalnızca JSON kabul ettiği için bu uyuşmazlık 415'e yol açabilir. İkinci istekte Content-Type: application/json kullanıldığı için istek gövdesinin türü sözleşmeyle eşleşir. Accept: application/json ise sunucudan beklenen yanıt türünü belirtir.

Gösterilen 200 OK yanıtı gerçek bir sağlayıcı vaadi değil, örnek sözleşmeye bağlı temsili bir sonuçtur. Yalnızca medya türü uyuşmazlığının kaldırılması 415 nedenini ortadan kaldırır; gövde sözleşmeye uygun değilse ayrıca bir doğrulama hatası alınabilir.

Sık Sorulan Sorular

415 Unsupported Media Type hatası ile 400 hatası arasındaki fark nedir?

415, sunucunun istekte belirtilen medya türünü kabul etmediğini veya gövde ile Content-Type arasında uyuşmazlık bulunduğunu gösterir. 400 ise kabul edilen medya türündeki gövdenin bozuk JSON, eksik alan ya da geçersiz veri yapısı gibi nedenlerle işlenemediği durumlarda görülür.

Content-Type application/json olduğu hâlde neden 415 alınabilir?

application/json yazılması tek başına endpoint'in JSON kabul ettiğini kanıtlamaz. Sözleşme başka bir medya türü bekliyor olabilir, istek yanlış endpoint'e ulaşabilir veya istemci ile sunucu arasındaki bir katman başlığı değiştirebilir. Gerçekte gönderilen başlıkları ve gövdeyi endpoint sözleşmesiyle birlikte kontrol et.

Accept başlığı yanlış olduğunda neden 406 görülebilir?

Accept istek gövdesini değil, istemcinin kabul edeceği yanıt biçimini belirtir. İstek gövdesi geçerli olduğu hâlde sunucu, Accept içinde belirtilen türlerden hiçbirini üretemiyorsa 406 dönebilir. Bu nedenle 406, çoğunlukla yanıt biçimi tercihiyle ilgilidir.

İstek gövdesini, Content-Type başlığını ve Accept tercihini ayrı ayrı kontrol ettiğinde 415, 400 ve 406 hatalarını daha düzenli biçimde ayırt edebilirsin.