Mengapa sebuah perusahaan proxy menulis tentang kode status: kami adalah Geonode dan orang-orang mengarahkan lalu lintas API melalui kami, sehingga kami sering ditanya apakah suatu kesalahan tertentu disebabkan oleh "proxy". Untuk kode 415, jawabannya pada dasarnya selalu tidak. Kode 415 berasal dari server asal dan menjelaskan sesuatu tentang permintaan yang Anda buat. Sebuah perantara dapat menghasilkan kode ini dalam keadaan tertentu — misalnya, proxy penyaring yang memeriksa isi permintaan, atau gateway dengan aturan kontennya sendiri — tetapi hal ini jarang terjadi dan akan diumumkan dalam header respons. Jika Anda menerima kode status 415 melalui proxy, lepaskan proxy tersebut dan Anda hampir pasti akan menerima kode status 415 yang sama secara langsung. Perbaiki permintaan tersebut. Satu-satunya kode status yang benar-benar menunjukkan keterlibatan proxy adalah 407, dan hal itu sudah tertera dalam namanya.
Sekarang, mengenai kesalahan yang sebenarnya.
Apa yang Tercantum dalam Spesifikasi
RFC 9110, Bagian 15.5.16, menjelaskannya secara tepat:
Kode status 415 (Unsupported Media Type) menunjukkan bahwa server asal menolak untuk memproses permintaan karena konten berada dalam format yang tidak didukung oleh metode ini pada sumber daya tujuan.
Tiga bagian dari kalimat tersebut memang benar.
"Konten" — isi permintaan (request body), bukan URL, bukan string kueri, bukan respons. Jika permintaan Anda tidak memiliki isi, kode 415 tergolong tidak biasa dan mengindikasikan adanya masalah lain.
"Tidak didukung oleh metode ini" — dukungan ditentukan per metode. Sebuah sumber daya mungkin menerima application/json pada metode POST dan menolaknya pada metode PATCH, yang memang sering menjadi sumber kebingungan ketika titik akhir yang sama berperilaku berbeda di bawah kata kerja yang berbeda.
"Pada sumber daya yang dituju" — dan per sumber daya. Satu titik akhir pada sebuah API yang menerima suatu format tidak memberi petunjuk apa pun mengenai titik akhir lainnya.
Spesifikasi tersebut kemudian menyebutkan penyebabnya:
Masalah format mungkin disebabkan oleh Content-Type atau Content-Encoding yang ditunjukkan dalam permintaan, atau sebagai hasil dari pemeriksaan data secara langsung.
Klausul terakhir ini penting dan sering diabaikan. Server diperbolehkan mengembalikan kode status 415 setelah memeriksa byte data, bukan hanya setelah membaca header. Menyatakan Content-Type: application/json dan mengirimkan sesuatu yang bukan JSON dapat secara sah menghasilkan kode status 415 alih-alih 400.
RFC juga menentukan apa yang seharusnya diberitahukan oleh server kepada Anda. Jika masalahnya terletak pada pengkodean konten, RFC menyatakan bahwa header respons Accept-Encoding "seharusnya digunakan untuk menunjukkan pengkodean konten mana (jika ada) yang akan diterima". Jika masalahnya terletak pada tipe media, Accept "dapat digunakan untuk menunjukkan tipe media mana yang akan diterima". Dalam praktiknya, dokumen MDN menyebutkan bahwa server umumnya menggunakan Accept-Post dan Accept-Patch untuk kasus-kasus yang spesifik metode, yang bahkan lebih berguna.
Baca header respons. Server sering kali memberi tahu Anda jawabannya, namun klien sering kali mengabaikannya.
Enam Hal yang Menyebabkannya
Dalam urutan kasar berdasarkan seberapa sering kami menemukannya.
1. Sama sekali tidak mencantumkan Content-Type. Anda mengirimkan body tetapi tidak pernah mendeklarasikan formatnya. Banyak framework tidak akan menebaknya. Contoh dari MDN persis seperti ini: permintaan POST dengan body JSON, Content-Length, dan tanpa Content-Type, yang dibalas dengan 415 dan Accept-Post: application/json; charset=UTF-8.
2. Tipe media yang salah (Content-Type). Kesalahan klasik adalah mengirim JSON sambil menyatakan application/x-www-form-urlencoded, biasanya karena klien HTTP secara default menggunakan form encoding dan Anda mengirim string JSON tanpa mengubahnya. Isi body-nya benar; labelnya yang salah.
3. Tipe media yang hampir benar tapi salah. text/json alih-alih application/json. application/xml padahal server menginginkan text/xml. Jenis vendor seperti application/vnd.api+json di mana Anda mengirimkan application/json biasa. Server yang ketat melakukan pencocokan yang tepat dan tidak akan bersikap toleran.
4. Masalah charset. MDN memberikan contoh yang paling jelas: mengirimkan UTF8 di mana server mensyaratkan UTF-8. Tanda hubung tidak opsional dalam nama yang terdaftar, dan server yang melakukan validasi parameter secara ketat berhak untuk menolaknya.
5. Format kompresi (Content-Encoding) yang tidak didukung server. Anda mengompresi badan permintaan dengan gzip dan menetapkan Content-Encoding: gzip ke server yang hanya menangani pengkodean identitas. RFC secara khusus mengantisipasi kasus ini, dan server yang berperilaku baik seharusnya mengembalikan Accept-Encoding untuk memberi tahu Anda format apa yang dibutuhkan.
6. Isi permintaan tidak sesuai dengan tipe yang dinyatakan. Header benar, byte salah — sering kali disebabkan oleh bug serialisasi, atau templat yang menghasilkan string kosong, atau isi permintaan yang mengalami pengkodean ganda di suatu tempat dalam tumpukan. Inilah penerapan klausul “memeriksa data secara langsung”.
415 vs 406 vs 400 vs 422
Inilah peta kebingungan, dan spesifikasinya membedakan ketiganya dengan jelas.
| Kode | Artinya | Arah | Perbaikan dengan mengubah |
|---|
| 415 | Format yang Anda kirim tidak didukung | Isi permintaan | Content-Type atau Content-Encoding |
| 406 | Tidak ada representasi yang Anda terima tersedia | Respons | Header Accept |
| 400 | Permintaan tidak valid | Seluruh permintaan | Sintaksis atau struktur |
| 422 | Format dipahami, konten tidak dapat diproses | Isi permintaan | Data itu sendiri |
| 413 | Isi terlalu besar | Isi permintaan | Ukuran muatan |
Perbedaan antara 415 dan 406 adalah masalah arah dan paling mudah dipahami setelah dijelaskan. 415 berkaitan dengan apa yang Anda kirim. 406 berkaitan dengan apa yang Anda minta untuk diterima — RFC 9110 mendefinisikannya sebagai sumber daya yang tidak memiliki "representasi terkini yang dapat diterima oleh agen pengguna, sesuai dengan bidang header negosiasi proaktif yang diterima". Jika Anda menerima kode status 406, periksa header Accept Anda, bukan isi pesan (body).
415 versus 400. RFC 9110 menjelaskan 400 sebagai kondisi di mana server tidak memproses permintaan "karena sesuatu yang dianggap sebagai kesalahan klien (misalnya, sintaks permintaan yang salah, pembingkaian pesan permintaan yang tidak valid, atau rute permintaan yang menyesatkan)". Kode 400 bersifat struktural — permintaan itu sendiri rusak. Kode 415 adalah permintaan yang terbentuk dengan benar, namun isi (body) permintaan tersebut berada dalam format yang tidak diterima oleh server. Dalam praktiknya, banyak server mengembalikan kode 400 padahal kode 415 akan lebih tepat; Anda tidak dapat mengendalikan hal ini, jadi anggaplah kode 400 pada permintaan dengan isi sebagai kemungkinan kode 415 yang terselubung.
Perbedaan antara 415 dan 422 adalah perbedaan yang paling jelas dijelaskan dalam RFC. Bagian 15.5.21 menyatakan bahwa 422 menunjukkan "server memahami tipe konten dari isi permintaan (oleh karena itu kode status 415 (Unsupported Media Type) tidak tepat), dan sintaks isi permintaan benar, tetapi server tidak dapat memproses instruksi yang terkandung di dalamnya."
Jadi urutannya adalah: 415 berarti pembungkusnya salah, 422 berarti pembungkusnya benar tetapi isinya salah. JSON yang terbentuk dengan baik namun kekurangan bidang yang diwajibkan adalah 422. JSON yang sama yang diberi label sebagai data formulir adalah 415.
Mendiagnosis Masalah dalam Waktu Kurang dari Dua Menit
Urutan langkah tetap yang dapat menyelesaikan hampir semua kasus.
Langkah pertama: baca header respons. Bukan baris status, melainkan header-nya.
curl -i -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
Cari Accept, Accept-Post, Accept-Patch, atau Accept-Encoding dalam respons. Jika salah satunya ada, itu adalah pernyataan langsung tentang apa yang diinginkan server dan Anda sudah selesai.
Langkah kedua: pastikan apa yang sebenarnya Anda kirim. Bukan apa yang Anda maksudkan untuk dikirim — melainkan apa yang benar-benar dikirim melalui jaringan. Pustaka klien menambahkan, mengganti, dan memformat ulang header, dan header yang Anda tetapkan dalam kode tidak selalu sama dengan header yang dikirimkan.
curl -v -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}' 2>&1 | grep '^>'
Baris-baris > adalah permintaan Anda yang sebenarnya. Sebagian besar kode status 415 dapat diselesaikan tepat di sini, ketika Content-Type yang Anda tetapkan dengan cermat ternyata telah diganti oleh nilai default.
Langkah ketiga: periksa metodenya. Endpoint yang sama dapat menerima suatu tipe pada POST dan menolaknya pada PATCH. Cobalah body yang sama dengan verb yang berbeda dan lihat apakah perilakunya berubah.
Langkah keempat: periksa string tipe yang tepat. Bandingkan karakter demi karakter dengan dokumentasi. application/json versus text/json. UTF-8 versus UTF8. Sufiks vendor. Ini memang membosankan, tetapi sering kali di sinilah letak jawabannya.
Langkah kelima: baca dokumentasi untuk endpoint tersebut. API tidak seragam secara internal. Endpoint unggah file yang meminta multipart/form-data dalam API JSON yang lain adalah hal yang sepenuhnya normal.
Memperbaikinya di Sisi Klien
Kasus-kasus umum pada klien yang umum digunakan.
curl. -d secara implisit berarti application/x-www-form-urlencoded kecuali Anda menentukan sebaliknya. Inilah penyebab paling umum munculnya kode status 415 saat menggunakan baris perintah:
curl -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
JavaScript fetch. Mengirimkan body berupa string sama sekali tidak menetapkan nilai Content-Type:
await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "test" }),
});
Pengecualian yang perlu diketahui: dengan FormData, jangan atur Content-Type sendiri. Browser harus menghasilkannya karena header tersebut mencakup batas multipart, dan menggantinya akan menghasilkan permintaan yang rusak yang sering kali ditandai dengan kode status 415.
Python requests. Gunakan json= daripada data= dan header tersebut akan diatur secara otomatis:
requests.post(url, json={"name": "test"}) # application/json
requests.post(url, data={"name": "test"}) # form-encoded
Axios. Mengatur application/json untuk objek biasa dan pengaturan lain untuk string, yang sering menjadi sumber kebingungan. Jika Anda telah menserialisasi payload Anda, atur header tersebut secara eksplisit. Perbedaan perilaku antar klien di sini persis seperti yang kita bahas dalam axios vs fetch.
Aturan umum: ketika klien menawarkan parameter khusus JSON, gunakanlah parameter tersebut daripada melakukan serialisasi secara manual dan berharap header defaultnya sudah benar.
Mengembalikan Respons dengan Benar di Sisi Server
Jika Anda berada di sisi penerima, ada beberapa hal yang dapat membuat API Anda jauh lebih mudah digunakan.
Kirimkan header Accept-Post atau Accept-Patch bersama kode status 415. RFC merekomendasikan Accept atau Accept-Encoding; varian yang spesifik metode ini lebih tepat, dan MDN mendokumentasikannya khusus untuk penggunaan ini. Header tunggal ini mengubah sesi debugging menjadi sekilas informasi.
Sertakan isi pesan yang mudah dibaca. Kode status dengan isi pesan kosong memaksa klien untuk menebak. Jelaskan apa yang Anda terima dan apa yang Anda harapkan.
Bedakan 415 dari 422 dengan benar. Jika Anda memahami tipe konten dan isi pesan telah diparsing tetapi gagal validasi, itu adalah kode 422. Mengembalikan kode 415 untuk kegagalan validasi akan membuat orang memeriksa header mereka padahal header tersebut sebenarnya baik-baik saja, dan ini merupakan kesalahan umum dan merugikan dalam desain API.
Berikan toleransi terhadap parameter jika memungkinkan. Menolak application/json; charset=utf-8 saat Anda menerima application/json secara teknis dapat dibenarkan, tetapi secara praktis tidak membantu. Parsing jenis media dengan benar dan abaikan parameter yang tidak Anda perlukan.
Jangan gunakan kode status 415 sebagai penolakan umum. Kode ini memiliki arti khusus. Penggunaan berlebihan akan membuat API Anda lebih sulit digunakan dan menyebabkan logika percobaan ulang di sisi klien menjadi salah.
Ketika Kode Status 415 Sebenarnya Bukan 415
Kasus-kasus di mana kode status dapat menyesatkan.
Gateway atau WAF menolak permintaan tersebut. Beberapa lapisan keamanan mengembalikan kode 415 untuk isi permintaan yang mereka anggap mencurigakan, terlepas dari jenis konten yang sebenarnya. Petunjuknya biasanya berupa isi respons yang tidak tampak berasal dari aplikasi, atau header yang mengidentifikasi perantara.
Pengaturan default framework dijalankan sebelum kode Anda dieksekusi. Banyak kerangka kerja web menolak jenis konten yang tidak dikenal di middleware. Penanganan Anda tidak pernah dieksekusi, sehingga tidak ada bagian dari logika aplikasi Anda yang relevan untuk perbaikan.
Sebuah load balancer atau CDN menghapus sebuah header. Jarang terjadi, tetapi nyata. Jika permintaan berhasil saat dikirim langsung dan gagal melalui infrastruktur, bandingkan header di kedua ujung sebelum berasumsi bahwa aplikasi yang berubah.
Endpoint tersebut tidak ada. Beberapa server merespons rute yang tidak cocok pada permintaan POST dengan kode status 415 alih-alih 404, karena negosiasi tipe konten terjadi sebelum penentuan rute diselesaikan. Periksa URL-nya.
Penggantian metode HTTP gagal. Jika kerangka kerja Anda mendukung penggantian metode melalui header atau parameter kueri, metode yang berlaku mungkin bukan yang Anda kirimkan, dan dukungan tipe konten bergantung pada masing-masing metode.
Dalam setiap kasus ini, solusinya terletak di hulu dari payload Anda. Prinsip umumnya: jika permintaan jelas-jelas benar dan kode status 415 tetap muncul, hentikan pengeditan badan permintaan dan mulailah mencari tahu komponen mana dalam jalur yang menghasilkan respons tersebut.
Pertanyaan Lainnya
Apa arti 415 Unsupported Media Type?
Server menolak permintaan tersebut karena format isi permintaan (request body) tidak didukung untuk metode tersebut pada sumber daya (resource) tersebut. RFC 9110 mengaitkannya dengan header Content-Type, header Content-Encoding, atau pemeriksaan langsung isi permintaan oleh server. Ini berkaitan dengan format yang Anda kirimkan, bukan kebenaran data itu sendiri.
Bagaimana cara memperbaiki kesalahan 415?
Periksa header respons terlebih dahulu — server sering kali mengembalikan Accept, Accept-Post, atau Accept-Encoding yang menyebutkan secara tepat apa yang mereka inginkan. Kemudian, verifikasi apa yang sebenarnya dikirimkan oleh klien Anda, karena pustaka dapat menggantikan header. Solusi tunggal yang paling umum adalah menambahkan Content-Type: application/json ke permintaan yang sebelumnya tidak memilikinya.
Apa perbedaan antara 415 dan 400?
400 berarti permintaan tidak valid — sintaks atau struktur yang salah. 415 berarti permintaan valid tetapi isi (body) berada dalam format yang tidak didukung. Dalam praktiknya, server sering kali mengembalikan kode 400 padahal kode 415 akan lebih tepat, sehingga kode 400 pada permintaan yang memiliki isi perlu diselidiki sebagai kemungkinan masalah tipe konten.
Apa perbedaan antara kode 415 dan 422?
RFC 9110 secara eksplisit membedakan keduanya: kode 422 berarti server memahami tipe konten dan sintaksnya benar, tetapi tidak dapat memproses instruksi tersebut. Jadi, kode 415 menunjukkan bahwa pembungkusnya salah; sedangkan kode 422 menunjukkan bahwa isinya yang salah. JSON yang valid namun kehilangan bidang yang wajib diisi akan menghasilkan kode 422.
Mengapa saya mendapatkan kode 415 saat mengunggah berkas?
Biasanya karena Content-Type diatur secara manual pada permintaan multipart. Browser atau klien harus menghasilkan header tersebut sendiri, karena header tersebut berisi batas multipart. Mengaturnya sendiri akan menghapus batas tersebut dan menghasilkan permintaan yang tidak dapat diparsing oleh server.
Apakah proxy dapat menyebabkan kode status 415?
Jarang. Kode status 415 berasal dari server asal dan menggambarkan isi permintaan Anda. Proksi penyaring atau gateway yang memeriksa konten dapat menghasilkan kode ini, tetapi kode status khusus proksi yang umum adalah 407, yang sudah dijelaskan dalam namanya. Coba tanpa proksi — jika kode 415 tetap muncul, proksi tidak terlibat.
Apakah kode 415 berarti JSON saya tidak valid?
Tidak selalu. Jika server menolak tipe kontennya, JSON Anda tidak pernah diperiksa. Jika server menyatakan tipe yang benar dan kemudian menemukan bahwa isi permintaan sebenarnya tidak sesuai dengan format tersebut, maka ya — RFC mengizinkan penolakan setelah "memeriksa data secara langsung". Periksa dulu masalah header; hal ini jauh lebih umum terjadi.
Haruskah saya mencoba lagi setelah mendapat kode 415?
Tidak. Ini adalah kesalahan klien dan permintaan yang sama akan menghasilkan hasil yang sama. Mencoba lagi hanya akan membuang-buang permintaan dan, jika Anda terkena batasan frekuensi, dapat memperburuk keadaan. Perbaiki tipe konten dan kirim sekali saja.
Kesimpulan
Kode status 415 memiliki arti yang sempit dan spesifik: pembungkus (wrapper) yang mengelilingi data Anda bukanlah jenis yang diterima oleh endpoint ini untuk metode ini. Ini bukan berarti data Anda tidak valid—hal itu ditangani oleh kode status 422—dan juga bukan mengenai apa yang Anda minta untuk diterima—hal itu ditangani oleh kode status 406.
Karena maknanya terbatas, diagnosisnya pun singkat. Periksa header respons, karena server yang baik biasanya mencantumkan tipe-tipe yang diterima dalam Accept, Accept-Post, atau Accept-Encoding. Kemudian, verifikasi apa yang sebenarnya dikirimkan oleh klien Anda melalui jaringan, bukan apa yang Anda perintahkan kepadanya, karena pengaturan default dan middleware sering kali menggantikan header yang Anda tetapkan. Dengan dua langkah tersebut, Anda akan dapat menyelesaikan sebagian besar kasus tanpa perlu menyentuh isi permintaan sama sekali.
Dan jika permintaan terlihat tidak bermasalah namun kode status 415 tetap muncul, respons tersebut kemungkinan besar tidak berasal dari aplikasi yang Anda duga. Gateway, middleware kerangka kerja, dan rute yang tidak cocok semuanya menghasilkan kode status 415 yang tidak ada hubungannya dengan muatan Anda — pada titik ini, pertanyaan yang berguna bukanlah apa yang harus diubah, melainkan komponen mana dalam jalur tersebut yang memberikan respons.
