Lỗi 415 Unsupported Media Type và cách sửa request API

lỗi 415 Unsupported Media Type xuất hiện khi bên nhận không chấp nhận định dạng nội dung gửi lên. Anh em cần so header với byte thực tế, phân biệt JSON, form và dữ liệu nén. Đổi địa chỉ gateway không sửa được một payload khai báo sai. ProxyVN hướng dẫn anh em kiểm đúng lớp gây lỗi và giữ bằng chứng trước khi thay cấu hình.

Lỗi 415 Unsupported Media Type nằm ở phần nội dung gửi lên

Điểm cần kiểm đầu tiên là hợp đồng của endpoint. Một API nhận JSON có thể từ chối form, trong khi một API upload lại yêu cầu multipart. Cùng nội dung nghiệp vụ nhưng cách đóng gói khác nhau sẽ đi vào bộ xử lý khác nhau. Vì vậy, hãy tìm định dạng mà tuyến API đó công bố trước khi đổi thư viện, tài khoản hay gateway.

Theo mô tả mã 415 của MDN, nguyên nhân có thể liên quan Content-Type, Content-Encoding hoặc việc kiểm tra nội dung thực nhận. Đây là căn cứ phân loại, không phải lời khẳng định mọi server trả mã giống nhau. Framework có thể phát sinh lỗi trước khi hàm xử lý nghiệp vụ chạy; gateway API cũng có thể từ chối request tại lớp kiểm tra schema.

Header và payload phải mô tả cùng một dữ liệu

Content-Type là nhãn mô tả nội dung, không phải thao tác chuyển đổi. Gắn application/json lên chuỗi dạng a=1 không biến chuỗi đó thành JSON. Tương tự, đổi nhãn của tệp nhị phân sang text/plain không khiến API có bộ giải mã phù hợp. Cần kiểm cả giá trị header lẫn dữ liệu đã serialize, nhất là khi một lớp middleware tự ghi đè cấu hình của lớp gọi phía trên.

Khi API nhận một đối tượng JSON, chuỗi JSON bị bọc thêm dấu nháy có thể vẫn đúng cú pháp nhưng sai kiểu dữ liệu mong đợi. Lỗi sau bước phân tích này thường cần đọc thông báo validation, thay vì kết luận cứ JSON là phải được chấp nhận. Tách khả năng đọc định dạng khỏi khả năng xử lý giá trị giúp anh em sửa đúng tầng và không dùng 415 như tên gọi cho mọi lỗi nhập liệu.

Phân biệt với Accept và mã 406

Content-Type trong request nói anh em đang gửi gì. Accept nói anh em muốn nhận kiểu phản hồi nào. Hai câu hỏi thuộc hai chiều khác nhau, nên thêm Accept: application/json chưa sửa được body đang gửi theo form. Nếu máy chủ không có biểu diễn đầu ra phù hợp với Accept, tình huống đó gần với 406 hơn; bài kiểm 415 nên giữ Accept cố định để không trộn nguyên nhân.

Proxy auth cũng thuộc một lớp khác. Một phản hồi 407 yêu cầu xác thực gateway không xác nhận máy chủ nguồn đã đọc payload. Ngược lại, một thông báo media type từ API có thể cho thấy request đã tới bộ xử lý nội dung. Chỉ suy ra đường đi từ log phù hợp, vì tên Server hay hình thức trang lỗi có thể bị thay đổi trên đường truyền.

Lỗi 415 Unsupported Media Type khi dùng JSON và form

Hãy chọn một kiểu gửi dựa vào tài liệu API, sau đó để thư viện tạo nội dung nhất quán. Đừng ghép vài mẹo lấy từ những ví dụ khác endpoint. Với công cụ dòng lệnh, kiểm tham số gửi dữ liệu tự đặt Content-Type nào; với SDK, kiểm nó serialize đối tượng hay chỉ truyền chuỗi có sẵn. Một cấu hình đúng tại nơi khai báo chưa chứng minh byte gửi ra cuối cùng cũng đúng.

JSON cần kiểm encoding và lớp serialize

JSON nên được tạo bằng bộ serialize của ngôn ngữ thay vì nối chuỗi từ đầu vào. Dấu nháy, dấu xuống dòng và ký tự tiếng Việt dễ làm lộ lỗi nối tay. Trong ca thử, dùng một trường nhỏ đã biết trước, gửi byte UTF-8 rồi đọc lại giá trị bên server. Không cần dùng hồ sơ khách hàng để chứng minh lỗi định dạng; dữ liệu tối giản giúp so sánh rõ hơn và dễ chia sẻ hơn.

Tài liệu Content-Type giải thích vai trò của media type và tham số đi kèm. Với charset, phải theo quy định của loại dữ liệu và API đang dùng; đừng tự thêm một nhãn lạ rồi chờ server đoán. Nếu endpoint chỉ công bố một media type cụ thể, giữ đúng nó trong ca cơ sở trước khi thử tham số bổ sung hoặc loại vendor có hậu tố +json.

Form URL encoded khác multipart

Form URL encoded biểu diễn các cặp khóa và giá trị theo quy tắc riêng. Multipart chia nội dung thành nhiều phần và cần boundary ăn khớp với body. Khi dùng thư viện upload, thường nên để thư viện tạo boundary; tự đặt một Content-Type multipart chung chung có thể làm mất giá trị boundary mà bộ đọc cần. Dấu hiệu cần kiểm là header thực gửi, tên trường và cách file được đặt trong từng phần.

Một endpoint đăng nhập nhận form không có nghĩa endpoint tạo tài nguyên cũng nhận form. Các tuyến trong cùng ứng dụng có thể dùng bộ phân tích khác nhau. Anh em nên lưu một mẫu thành công cho từng thao tác, gồm method, đường dẫn, nhãn media type và cấu trúc body. Bản mẫu đó tốt hơn một cấu hình mặc định áp lên mọi request, đặc biệt khi worker vừa upload tệp vừa gọi API JSON.

Header và byte nội dung

Lỗi 415 Unsupported Media Type với nén và middleware

Nếu header và JSON có vẻ đúng nhưng lỗi vẫn xuất hiện, kiểm lớp đóng gói bên ngoài. Content-Encoding mô tả phép biến đổi như gzip đã áp lên nội dung. Khai gzip mà gửi byte chưa nén, hoặc nén thật nhưng thiếu nhãn phù hợp, đều khiến bên nhận khó xử lý. Đừng nhầm việc client chấp nhận phản hồi gzip với việc server chấp nhận request gzip.

Content Encoding phải khớp dữ liệu đã nén

Tài liệu Content-Encoding giúp xác định thứ tự đọc: giải mã phép biến đổi rồi mới diễn giải media type. Trong lab, nên bỏ nén request ở mốc đầu để giảm biến số. Sau khi mốc JSON thường hoạt động, mới thêm đúng một lớp gzip nếu API có công bố hỗ trợ. Không suy ra khả năng nhận request nén chỉ từ việc cùng server gửi response nén.

Nếu nhiều lớp cùng có chức năng nén, hãy xác định lớp nào thực sự thực hiện. Một middleware có thể nén lại nội dung đã nén hoặc giữ Content-Length cũ sau khi biến đổi. Khi phân tích lỗi, ghi kích thước trước và sau serialize, sau nén và tại nơi nhận. Những số đo này là dữ liệu kỹ thuật của ca thử; không cần lưu nguyên body có bí mật để hiểu lớp nào làm thay đổi thông điệp.

Gateway có thể kiểm trước ứng dụng

API gateway có thể kiểm media type và schema trước khi chuyển vào upstream. Trong trường hợp đó, ứng dụng không có access log tương ứng là một dữ kiện cần điều tra, không phải bằng chứng API không nhận kết nối mạng. So mã request từ lớp gateway với log ứng dụng trong cùng khoảng thời gian. Nếu có trace ID, dùng nó để nối hai bên; nếu không, giữ ca thử ít request để tránh ghép sai.

Một forward proxy thông thường không được dùng làm bộ sửa payload. Nếu tổ chức có lớp kiểm tra hoặc chuyển đổi HTTP, phải biết chính sách của lớp đó và so dữ liệu tại cả hai phía. Với HTTPS xuyên tunnel, proxy không mặc nhiên nhìn thấy Content-Type bên trong TLS. Chỉ ghi rằng nó sửa header khi có cấu hình và bằng chứng phù hợp, tránh đoán từ việc request đi qua cùng một địa chỉ.

Lỗi 415 Unsupported Media Type trong endpoint lab nhận JSON

Ví dụ sau tự tạo một server HTTP trên loopback. Nó chỉ nhận JSON ở POST, dùng 415 cho media type khác và 400 cho JSON sai cú pháp. Đây là quy tắc của fixture minh họa, không phải quy tắc buộc mọi framework phải sao chép. Lưu mã thành lab415.py, chạy bằng Python 3; terminal giữ server hoạt động trong lúc gọi request từ cửa sổ khác.

import json
from http.server import BaseHTTPRequestHandler, HTTPServer
 
class API(BaseHTTPRequestHandler):
    def do_POST(self):
        body = self.rfile.read(int(self.headers.get('Content-Length', '0')))
        if self.headers.get_content_type() != 'application/json':
            status = 415
        else:
            try:
                json.loads(body)
                status = 200
            except (ValueError, UnicodeError):
                status = 400
        self.send_response(status)
        self.send_header('Content-Length', '0')
        self.end_headers()
 
HTTPServer(('127.0.0.1', 8765), API).serve_forever()

Server đọc số byte theo Content-Length và không triển khai chunked request. Vì vậy mẫu chỉ phù hợp cho payload nhỏ có độ dài xác định trong môi trường thử. Thư viện http.server của Python là công cụ dựng fixture thuận tiện; không dùng mẫu này làm API sản xuất. Nếu cổng 8765 đã được sử dụng, chọn cổng khác và sửa cả lệnh client tương ứng.

Ba request giữ nguyên body

Tạo file payload.json chỉ chứa đối tượng {"x":1}, lưu UTF-8. Ba lệnh dưới dùng curl.exe để tránh nhầm với alias trong Windows PowerShell. Cùng một nội dung được gửi với ba nhãn khác nhau; anh em có thể nhìn status thay đổi trong khi byte của file giữ nguyên. Sau đó thử JSON sai cú pháp với nhãn đúng để thấy lý do tách 400 khỏi 415 trong fixture này.

curl.exe -i -H "Content-Type: application/json" --data-binary "@payload.json" http://127.0.0.1:8765/json
curl.exe -i -H "Content-Type: text/plain" --data-binary "@payload.json" http://127.0.0.1:8765/json
curl.exe -i -H "Content-Type: application/x-www-form-urlencoded" --data-binary "@payload.json" http://127.0.0.1:8765/json

Đọc kết quả thử nghiệm đúng phạm vi

Trong kiểm thử cục bộ của bài, ba cặp media type trên được chạy trực tiếp và qua forward proxy HTTP loopback. Cả hai đường cho cùng trạng thái 200, 415, 415; JSON sai cú pháp cho 400 ở fixture. Kết quả chứng minh gateway chuyển tiếp không sửa cách khai báo sai trong ca này. Nó không xác nhận mọi proxy thương mại giữ nguyên nội dung hay mọi API phân loại lỗi giống mẫu.

Fixture dùng dữ liệu giả, không có auth và không có TLS. Nếu cần kiểm API thật, thay bằng endpoint được phép cùng tài khoản thử có quyền phù hợp. Không sao chép mã đơn giản rồi mở cổng ra Internet. Trọng tâm bài kiểm là liên hệ giữa nhãn và body; phần xác thực, giới hạn dung lượng, streaming và chữ ký phải có ca kiểm riêng khi đưa vào hệ thống vận hành.

Ma trận request JSON

Lỗi 415 Unsupported Media Type khi so client với request thực

Một lần gọi thành công bằng curl là mốc tham chiếu tốt, nhưng cần so đúng các trường với ứng dụng. Method, URL, body, media type, content encoding và redirect đều có thể khác. Khi so, bắt đầu từ một tài nguyên thử không tạo tác dụng phụ lớn. Đừng dùng lệnh tạo thanh toán hay gửi thư để dò từng header nếu API không có chế độ thử thích hợp.

Ghi lại request sau khi thư viện chuẩn bị

Trong ứng dụng, hãy tìm cách quan sát request đã được chuẩn bị ngay trước lớp truyền tải. Cấu hình đầu vào có thể còn chứa đối tượng, trong khi request thực đã thành chuỗi hoặc byte. Kiểm xem đối tượng có bị serialize hai lần không, có bị gửi theo form bởi tham số mặc định không, hoặc có một interceptor thêm nhãn cũ không. Những câu hỏi này thường cụ thể hơn việc đổi timeout.

Khi ghi log, chỉ giữ schema và kích thước của trường nhạy cảm, không ghi token hay dữ liệu cá nhân. Có thể dùng một body thử có cùng kiểu dữ liệu và độ lồng nhau mà không chứa giá trị thật. Nếu lỗi chỉ xảy ra với một ký tự, đưa ký tự đó vào mẫu tối giản được phép chia sẻ. Cách này vẫn giữ khả năng tái hiện mà không biến log chẩn đoán thành kho dữ liệu riêng tư.

Redirect có thể đổi đích xử lý

Một URL cũ có thể chuyển tới tuyến khác với hợp đồng nội dung khác. Vì vậy, xem chuỗi chuyển hướng trước khi nhận rằng cùng request tới cùng endpoint. Với các mã redirect khác nhau, client có thể xử lý method và body theo cách khác nhau; kiểm hành vi của thư viện đang dùng thay vì giả định. Trong ca cơ sở, gọi URL cuối được tài liệu chỉ định nếu anh em đã có quyền dùng trực tiếp.

Nếu lỗi xuất hiện sau chuyển hướng sang tên miền khác, rà việc truyền credential và header tùy chỉnh. Không bật tùy chọn gửi credential tới mọi host chỉ để vượt một lỗi định dạng. Cần xác nhận đích mới thuộc dịch vụ dự kiến rồi mới điều chỉnh client. Một chuỗi redirect sai là vấn đề tuyến API; thay media type ngẫu nhiên có thể chỉ che triệu chứng mà giữ nguyên lỗi đích nhận.

Lỗi 415 Unsupported Media Type và cách sửa theo bằng chứng

Mỗi nhánh sửa nên có một thay đổi cụ thể cùng điều kiện kiểm lại. Nếu API yêu cầu JSON mà client gửi form, đổi cách serialize và header đi cùng nó. Nếu API yêu cầu multipart, dùng bộ dựng multipart của thư viện. Nếu server từ chối gzip, kiểm khả năng hỗ trợ rồi gửi bản không nén ở ca đối chứng. Không cần đổi nhiều lớp trong cùng một lần gọi.

Khi chỉ sửa header là đủ và khi chưa đủ

Sửa header có thể đủ khi byte đã đúng định dạng mà nhãn khai sai. Đây chính là nhánh đối chứng của fixture: body JSON không thay đổi, nhãn được sửa từ text/plain sang application/json. Nhưng nếu body đang là form, chỉ sửa nhãn sẽ chuyển lỗi từ bước chọn parser sang bước phân tích. Kết quả có thể thành 400 hoặc lỗi riêng của API, và chưa phải một lần xử lý thành công.

Điều kiện kết thúc phải gồm status được API công bố và dữ liệu đầu ra phù hợp. Nếu endpoint trả 202 cho tác vụ nền, cần theo dõi kết quả tác vụ theo hợp đồng của nó. Nếu trả 200 nhưng body mô tả lỗi, phải xử lý nội dung đó. Không coi việc hết mã 415 là đủ khi request mới vẫn không hoàn thành công việc mà người dùng muốn thực hiện.

Khi hợp đồng API đã thay đổi

Nếu mẫu từng hoạt động rồi lỗi sau nâng phiên bản, đối chiếu changelog và phiên bản endpoint. Một loại media type cũ có thể bị ngừng nhận, hoặc API mới yêu cầu dạng vendor cụ thể. Giữ một ca kiểm nhỏ trong quy trình tích hợp để phát hiện thay đổi trước lô lớn. Bản kiểm nên ghi phiên bản SDK, URL phiên bản API và ví dụ response đã che dữ liệu, giúp nhóm khác nhận diện cùng biến cố.

Không suy ra lỗi do địa chỉ IP chỉ từ việc đổi mạng trùng thời điểm nâng SDK. Khi có hai thay đổi cùng lúc, đưa một biến về mốc đã biết hoặc chạy ma trận nhỏ giữa hai phiên bản. Nếu không tái tạo được mốc cũ, ghi rõ điều đó trong biên bản. Một kết luận chưa đủ bằng chứng vẫn hữu ích khi nó chỉ rõ lần thử tiếp theo, thay vì đưa ra nguyên nhân thiếu căn cứ.

Khoanh vùng lớp chuyển đổi

Lỗi 415 Unsupported Media Type trong worker và hàng đợi

Worker cần phân loại lỗi định dạng thành tác vụ cần sửa đầu vào. Lặp ngay cùng body và cùng header thường tạo thêm tải mà không thay đổi kết quả. Hãy giữ bản ghi lỗi có mã tác vụ, phiên bản bộ serialize và lý do ngắn gọn, rồi đưa vào luồng xử lý phù hợp. Không đưa nguyên payload có bí mật vào thông báo công khai hoặc kênh hỗ trợ chung.

Retry cần một thay đổi có ý nghĩa

Nếu sửa được nhãn mà request là thao tác có tác dụng phụ, vẫn phải kiểm chính sách retry của API. Một phản hồi trên đường truyền có thể không phản ánh toàn bộ trạng thái nghiệp vụ ở hệ thống phức tạp. Dùng idempotency key khi API hỗ trợ và theo dõi kết quả theo mã tác vụ. Không tạo khóa mới ở mỗi lần thử lại rồi coi đó là cùng một thao tác an toàn.

Trong hàng đợi, nên phân biệt số lần truyền tải với số lần sửa payload. Một tác vụ bị 415 do phiên bản client cũ cần triển khai bản sửa hoặc chuyển định dạng có kiểm soát. Tăng ngân sách retry không giải quyết nguyên nhân đó. Sau khi sửa, thử một nhóm dữ liệu nhỏ đại diện cho kiểu chuỗi, số, null và cấu trúc lồng nhau trước khi giải phóng toàn bộ tác vụ đang chờ.

Theo dõi chất lượng sau bản sửa

Theo dõi tỷ lệ theo endpoint và phiên bản client sẽ hữu ích hơn một tổng số 415 cho toàn dịch vụ. Một tuyến upload có thể lỗi trong khi API JSON vẫn bình thường. Nếu log giữ được media type không nhạy cảm, nhóm vận hành dễ thấy mẫu sai tập trung ở một producer. Tuy nhiên, số lượng lỗi giảm chỉ là một phần; cần kiểm cả số tác vụ thành công và số dữ liệu bị bỏ qua.

Một bản sửa có thể làm status chuyển từ 415 sang 400 hoặc 422. Đừng báo đã xử lý xong chỉ vì biểu đồ mã cũ đi xuống. Hãy theo dõi dòng chảy tác vụ tới đầu ra cuối, kiểm schema và dữ liệu nghiệp vụ. Việc phân nhóm lỗi rõ ràng giúp đội hỗ trợ biết phải hỏi mẫu serialize hay hỏi quyền truy cập, thay vì yêu cầu người dùng thay toàn bộ cấu hình mạng.

Lỗi 415 Unsupported Media Type và hồ sơ kiểm lại

Hồ sơ bàn giao nên mô tả trước và sau bằng một request mẫu nhỏ. Ghi rõ trường nào đã thay, vì sao cần thay và API đã chấp nhận bằng dấu hiệu nào. Với ca liên quan proxy, thêm bằng chứng request tới đúng origin nhưng không ghi userinfo của gateway. Anh em có thể dùng hướng dẫn định dạng proxy để kiểm đầu vào mạng trước khi đánh giá payload.

Một bài tập tự kiểm trên fixture

Sau ba nhãn cơ bản, thử thay body thành một mảng JSON, một chuỗi JSON và một đối tượng rỗng. Fixture đơn giản vẫn trả 200 vì chỉ kiểm cú pháp, trong khi API nghiệp vụ có thể từ chối kiểu dữ liệu đó. Sự khác biệt giúp người đọc hiểu giới hạn của bài kiểm: chứng minh media type được chọn không đồng nghĩa chứng minh mọi giá trị được ứng dụng chấp nhận. Muốn kiểm schema, phải thêm quy tắc rõ ràng và ca âm tương ứng.

Tiếp theo, thử bỏ header Content-Type và quan sát giá trị mà công cụ tự thêm. Nếu kết quả khác dự đoán, xem request thực thay vì đổi server ngay. Bài tập này giúp phân biệt đầu vào anh em gõ với thông điệp thư viện gửi ra. Khi kiểm qua gateway, giữ cùng file payload và cùng endpoint; nếu còn quy tắc no_proxy, xác định request thực có đi qua điểm cần quan sát không.

Byte order mark và file JSON trên Windows

Khi tạo payload từ một trình soạn thảo hoặc shell, kiểm cách file được mã hóa và có byte order mark hay không. Đừng chỉ mở bằng mắt rồi nhận rằng nội dung giống nhau. Một fixture có thể nhận được dạng mã hóa mà API khác từ chối, nên ca cơ sở cần dùng encoding theo tài liệu của endpoint. Nếu lỗi chỉ xuất hiện với file tạo từ một công cụ, so vài byte đầu trong môi trường thử và quy trình ghi file trước khi đổi Content-Type hoặc proxy.

Kích thước Content-Length phải theo số byte thực gửi, không theo số ký tự của chuỗi tiếng Việt. Khi thư viện quản lý body, thường nên để nó đặt độ dài phù hợp thay vì tự tính bằng độ dài văn bản trước encode. Một giá trị sai có thể làm bên nhận chờ thêm, đọc thiếu hoặc đóng kết nối theo chính sách riêng. Trường hợp đó cần giữ cả lỗi truyền tải và lỗi nội dung được quan sát, không gán sẵn mọi biểu hiện thành 415.

Multipart cần kiểm tên trường và file

Nếu endpoint nhận multipart, một file đúng định dạng nhưng đặt dưới tên trường sai vẫn có thể bị ứng dụng từ chối. Phân biệt ba dữ kiện: media type của toàn request, boundary phân chia và tên cùng media type của từng phần. Khi dùng một SDK upload, so mẫu thành công từ tài liệu với request đã được chuẩn bị. Không tự đặt toàn request thành media type của file, vì lớp ngoài multipart và nội dung file là hai phần mô tả khác nhau.

Một ca kiểm tốt có file nhỏ với nội dung đã biết, tên trường đúng và một giá trị văn bản đơn giản. Sau khi mốc chạy, thêm file lớn hoặc trường tùy chọn từng bước. Nếu lỗi xuất hiện khi thêm một phần, kiểm schema và giới hạn của phần đó thay vì đổi toàn bộ cấu trúc request. Tách ca theo phần giúp đội API nhận một mẫu tái hiện ngắn, thay cho một upload phức tạp mà dữ liệu nhạy cảm phải được xử lý trước khi có thể chia sẻ.

Giữ hợp đồng lỗi trong kiểm thử tích hợp

Với API do nhóm quản lý, tài liệu nên nêu rõ định dạng nhận và hình thức lỗi khi định dạng không được hỗ trợ. Bộ kiểm tích hợp cần xác nhận response có thể được client đọc ngay cả khi status là lỗi. Nếu API dùng một schema lỗi riêng, kiểm Content-Type của response lỗi và nội dung cần thiết, không chỉ con số 415. Một client không parse được lỗi sẽ khiến thông tin hữu ích từ server mất đi và người dùng chỉ còn thấy exception chung khó điều tra.

Khi thêm hỗ trợ một định dạng mới, giữ ca định dạng cũ và ca không được hỗ trợ để tránh mở rộng ngoài ý định. Việc server nhận thêm một kiểu dữ liệu cần đi cùng bộ phân tích, giới hạn và validation phù hợp. Không thêm wildcard nhận mọi media type chỉ để làm bài kiểm hết lỗi; điều đó có thể làm sai ranh giới mà endpoint đã công bố và khiến dữ liệu không được kiểm đi sâu hơn vào ứng dụng.

Sửa đúng media type phải đi cùng việc kiểm byte nội dung và kết quả của endpoint.

Kiểm lại sau khi sửa

Nếu cần mua proxy cho luồng API được phép, anh em nên xác nhận giao thức và cách xác thực riêng với nhà cung cấp. Gateway phù hợp phục vụ đường truyền; hợp đồng media type và dữ liệu gửi lên vẫn do client cùng API quyết định.

Anh em nên giữ request mẫu, kết quả đối chứng và cấu hình đã che thông tin nhạy cảm để kiểm lại sau thay đổi. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi triển khai, đánh giá đúng phạm vi của lỗi 415 Unsupported Media Type.