HTTP 415 Hatası için Content-Type, API verisi ve WordPress HTTP başlıklarını karşılaştırarak Unsupported Media Type sorununun kaynağını belirleyin.
Bir API bağlantısı kurarken istek gönderiliyor, sunucuya ulaşılıyor fakat işlem başlamadan HTTP 415 Hatası dönüyorsa sorun çoğunlukla bağlantının kendisinde değildir. Sunucu, gelen verinin biçimini kabul etmiyordur. Özellikle JSON gönderilmesi gereken bir adrese form verisi yollamak veya doğru veriyle yanlış Content-Type kullanmak bu yanıtı tetikleyebilir.
415 kodunun adı Unsupported Media Type olsa da buradaki medya ifadesini yalnızca görsel, video ya da ses dosyası olarak düşünmemek gerekir. JSON ve form verisi gibi istek gövdelerinin de bir medya türü vardır. Bu nedenle HTTP 415 Hatası Nedenleri araştırılırken önce gönderilen dosyadan ziyade isteğin gövdesi ve HTTP başlıkları incelenmelidir. Güncel HTTP belgelerinde 415, sunucunun istek içeriğinin biçimini desteklemediği durumda verdiği istemci hata yanıtı olarak tanımlanır.
WordPress ile klasik HTML sitesi arasındaki fark, böyle bir sorunun nerede araştırılacağını da değiştirebilir. WordPress mi, Statik HTML mi Sitenizi Nasıl Oluşturmalısınız konusu iki yaklaşımın çalışma biçimini karşılaştırırken iyi bir başlangıç sağlar. WordPress tarafında istek bir eklenti veya tema kodundan çıkabilirken statik bir yapıda problem kullanılan JavaScript ya da harici servis bağlantısında bulunabilir.

HTTP 415 Hatası ne anlama gelir?
HTTP 415 Hatası, sunucunun gelen isteğin içerik biçimini desteklemediğini gösterir. Sorun çoğunlukla Content-Type veya Content-Encoding değerinden ya da gönderilen verinin bu başlıklarla uyuşmamasından kaynaklanır. Sunucu JSON beklerken farklı biçimde veri gönderilmesi buna tipik bir örnektir.
Asıl ipucu çoğu zaman isteğin kendisindedir.
Örneğin bir API yalnızca application/json kabul ediyorsa aşağıdaki başlıkla istek gönderilmesi beklenebilir:
Content-Type: application/json
Fakat gövdede JSON bulunmasına rağmen Content-Type değeri application/x-www-form-urlencoded olarak gönderilirse sunucu veriyi beklediği biçimde değerlendiremeyebilir ve 415 döndürebilir. MDN’nin güncel örneklerinde de eksik veya yanlış Content-Type değerinin bu sonucu oluşturabildiği gösteriliyor.
Content-Type ile Content-Encoding aynı şey mi?
Değil.
Content-Type, gönderilen içeriğin ne olduğunu söyler. JSON, HTML veya JPEG gibi değerler burada tanımlanır.
Content-Encoding ise veriye iletim öncesinde uygulanmış kodlama veya sıkıştırmanın nasıl çözüleceğini belirtir. Örneğin sıkıştırılmış bir istek gövdesinde kullanılan kodlama sunucu tarafından desteklenmiyorsa yine HTTP 415 Hatası ortaya çıkabilir.
Bu ikisini karıştırmak hata ayıklarken gereksiz yere dosya uzantılarına odaklanılmasına yol açıyor.
Gönderilen veri ile Content-Type eşleşiyor mu?
İlk gerçek kontrol burada yapılmalı. Tarayıcının Geliştirici Araçları > Network bölümünden başarısız isteği açın. Headers alanında Content-Type değerine, ardından gönderilen request payload bölümüne bakın.
JSON gönderiliyorsa gövdenin de gerçekten JSON biçiminde olması gerekir.
Örneğin WordPress içinde harici bir API’ye JSON gönderen istek şu yapıya yakın olabilir:
$data = array(
'name' => 'Deneme',
'status' => 'active',
);
$response = wp_remote_post(
$url,
array(
'headers' => array(
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( $data ),
)
);
WordPress’in güncel HTTP API belgelerinde wp_remote_post() fonksiyonunun istek seçenekleri içinde headers ve body alanlarını kabul ettiği görülüyor. Fonksiyonun dönüş değeri de yanıt dizisi veya WP_Error olabilir.
Ben bu tip bağlantıları incelerken yalnızca başlığa bakmıyorum. Content-Type: application/json doğru görünmesine rağmen gövdenin normal PHP dizisi olarak bırakıldığı örneklerle karşılaştım. Ekranda başlık doğru olduğu için sorun uzun süre başka yerde aranabiliyor. Başlık ile gerçek payload birlikte kontrol edilince hata daha görünür hale geliyor.

WordPress kodunda küçük bir yazım hatası 415 oluşturabilir mi?
Evet. Özellikle HTTP API seçenekleri oluşturulurken anahtar isimlerindeki küçük hatalar gönderilecek başlığın hiç uygulanmamasına yol açabilir.
Örneğin:
$args = array(
'header' => $headers,
);
yerine WordPress HTTP API’de kullanılan alan:
$args = array(
'headers' => $headers,
);
şeklindedir. Resmî WordPress örneklerinde de başlıklar headers anahtarı altında gönderilir.
Böyle bir durumda kod çalışıyor gibi görünebilir, istek karşı sunucuya ulaşabilir ve buna rağmen HTTP 415 Hatası alınabilir. Çünkü geliştiricinin eklediğini düşündüğü Content-Type gerçekte isteğe dahil edilmemiştir.
Sunucunun hangi biçimi kabul ettiği nasıl anlaşılır?
API belgesi varsa önce oraya bakın. Endpoint’in POST isteğinde JSON mı, form verisi mi yoksa başka bir içerik türü mü beklediği açıkça belirtilmelidir.
Bazı sunucular 415 yanıtıyla birlikte Accept-Post başlığı da gönderebilir. Bu başlık, ilgili kaynağın POST isteklerinde kabul ettiği medya türlerini göstermek için kullanılabilir. Örneğin sunucu Accept-Post: application/json döndürüyorsa istemci isteğini buna uygun hazırlamalıdır.
Accept ile Content-Type da aynı amaçla kullanılmaz. Content-Type gönderdiğiniz veriyi tanımlarken Accept, karşı taraftan hangi yanıt biçimini kabul ettiğinizi belirtir. Bu ayrımı netleştirmek HTTP 415 Hatası araştırmasını ciddi biçimde kısaltabilir.
Dosya yüklerken alınan 415 aynı şekilde mi ele alınır?
Temel mantık değişmez. Sunucu, isteğin içerik türünü kabul etmiyordur.
Fakat burada gerçek dosyanın MIME türü ile istekte bildirilen Content-Type değerini birlikte kontrol etmek gerekir. Bir yükleme alanı yalnızca belirli içerik türlerini işliyorsa desteklenmeyen biçim reddedilebilir.

WordPress Medya Kütüphanesi içinde görülen dosya türüne izin verilmiyor uyarısını da doğrudan 415 ile aynı problem kabul etmemek gerekir. Medya Kütüphanesi kendi dosya türü kontrollerini uygulayabilir. 415 ise HTTP isteğine karşı sunucudan gelen durum kodudur.
2026 itibarıyla HTTP 415 Hatası için en faydalı inceleme sırası hâlâ oldukça kısa: isteğin gövdesine bakın, Content-Type değerini karşılaştırın, varsa Content-Encoding kontrolünü yapın ve API’nin hangi biçimi kabul ettiğini doğrulayın. Kod tarafında WordPress HTTP API kullanılıyorsa headers ve body seçeneklerinin doğru oluşturulduğunu da inceleyin.
İstek başlıkları veya WordPress bağlantı kodu kontrol edildiği halde HTTP 415 Hatası devam ediyorsa daha ayrıntılı teknik inceleme gerekebilir. 11858, 2011 yılından bu yana Türkiye genelinde milyonlarca kullanıcıya 7/24 profesyonel teknik destek sağlıyor. Bilgisayar, akıllı TV, sosyal medya ve modem dahil farklı konularda çalışan ekip gerektiğinde TeamViewer ve AnyDesk gibi lisanslı araçlarla uzaktan bağlantı kurabiliyor. Hizmet dakika bazlı şeffaf ücretlendirme sistemiyle yürütülüyor; yüzde 95 memnuniyet oranı ve 500.000’den fazla başarılı işlem tecrübesi bulunuyor.
API bağlantıları özellikle SaaS projelerinde yalnızca hata çözme aşamasında değil, genel performans planlamasında da önem taşır. B2B SaaS için WordPress’i Optimize Etme konusu, WordPress’in harici servislerle daha yoğun çalıştığı yapılarda altyapı ve uygulama tarafının birlikte değerlendirilmesi açısından iyi bir devam noktasıdır. Bir isteği düzeltirken sitenin geri kalanındaki bağlantı davranışını gözden kaçırmamak gerekir.
HTTP 415 Hatası gördüğünüzde ilk refleks dosyayı değiştirmek olmamalı. Sunucunun ne beklediği ile sizin gerçekten ne gönderdiğinizi yan yana koymak çoğu zaman problemi görünür hale getirir. Siz 415 kodunu bir WordPress eklentisinde mi, özel API bağlantısında mı yoksa dosya yüklerken mi gördünüz? Yorumlarda paylaşabilirsiniz.