nieobsługiwany Content-Type

Nieobsługiwany Content-Type to nagłówek żądania wskazujący format, którego serwer nie potrafi przetworzyć.

Co oznacza nieobsługiwany Content-Type w żądaniu HTTP

Content-Type jest nagłówkiem HTTP opisującym format danych przesyłanych w treści żądania. Klient umieszcza go między innymi przy wysyłaniu formularza, pliku, dokumentu JSON albo danych XML. Serwer odczytuje tę wartość i na jej podstawie wybiera sposób dekodowania zawartości. Przykładowo application/json oznacza obiekt zapisany w składni JSON, application/xml wskazuje dokument XML, a text/plain zwykły tekst. Sam nagłówek nie zmienia zawartości danych; informuje tylko odbiorcę, jak powinien ją interpretować.

Komunikat „nieobsługiwany Content-Type” zwykle oznacza, że aplikacja otrzymała poprawne pod względem składni żądanie HTTP, ale nie ma procedury obsługi wskazanego typu danych. W standardowym API taka sytuacja jest często sygnalizowana kodem odpowiedzi 415 Unsupported Media Type. Kod 415 dotyczy formatu treści żądania, którego serwer nie akceptuje. Nie należy mylić go z kodem 400, oznaczającym niepoprawne żądanie, ani z kodem 406 Not Acceptable, który odnosi się przede wszystkim do braku odpowiedzi zgodnej z nagłówkiem Accept.

Różnica między Content-Type, Accept i formatem danych

Content-Type opisuje dane wysyłane przez klienta do serwera, natomiast Accept określa, jakie formaty odpowiedzi klient potrafi odebrać. W żądaniu POST aplikacja może więc wysłać JSON z nagłówkiem Content-Type: application/json i jednocześnie wskazać Accept: application/json, oczekując odpowiedzi także w formacie JSON. Te nagłówki pełnią różne funkcje i ustawienie jednego z nich nie zastępuje drugiego. Serwer może zaakceptować treść żądania, ale zwrócić odpowiedź w innym formacie, jeśli tak działa jego kontrakt API.

Częstym źródłem błędu jest wysłanie danych w jednym formacie przy oznaczeniu ich innym nagłówkiem. Dotyczy to na przykład przekazania tekstu zakodowanego jako parametry formularza z wartością application/json albo wysłania wieloczęściowego formularza z nagłówkiem application/x-www-form-urlencoded. Przy przesyłaniu pliku z formularza HTML stosuje się zwykle multipart/form-data, a przy prostych parach klucz-wartość application/x-www-form-urlencoded. Jeżeli endpoint został zaprojektowany wyłącznie dla JSON, wysłanie formularza może zakończyć się kodem 415, nawet gdy nazwy pól są prawidłowe.

Sprawdzanie nagłówka i kontraktu endpointu

Diagnozę należy rozpocząć od ustalenia dokładnego żądania, które zwraca błąd. W narzędziach przeglądarki można otworzyć kartę Network i sprawdzić metodę HTTP, adres, nagłówki oraz treść wysłaną w sekcji Request Payload albo Form Data. W programie klienckim trzeba zweryfikować, czy biblioteka nie ustawia automatycznie niewłaściwego nagłówka. Dla żądania JSON przykładowe wywołanie z użyciem curl ma postać curl -X POST https://example.test/api -H "Content-Type: application/json" -d "{\"name\":\"Jan\"}". Wartość nagłówka musi odpowiadać rzeczywistym bajtom przekazanym po opcji -d.

Następnie należy porównać żądanie z dokumentacją konkretnego endpointu. Istotne są dopuszczalne typy MIME, wymagane parametry, metoda HTTP oraz sposób kodowania znaków, na przykład application/json; charset=utf-8. Parametr charset zwykle nie zmienia głównego typu, ale niektóre starsze lub restrykcyjne implementacje mogą analizować nagłówek zbyt literalnie. Nie należy usuwać go automatycznie bez sprawdzenia kontraktu. Jeżeli serwer zwraca nagłówek Accept lub opisuje obsługiwane media types w dokumentacji, te informacje pomagają odróżnić błąd konfiguracji klienta od ograniczenia samego endpointu.

Jeżeli żądanie przechodzi przez proxy, bramę API albo filtr bezpieczeństwa, trzeba sprawdzić także logi warstwy pośredniej. Taki komponent może odrzucać typy takie jak application/octet-stream, zmieniać nagłówki albo ograniczać dozwolone metody. Zmiana Content-Type na przypadkową wartość nie jest prawidłową naprawą, ponieważ może spowodować błędne parsowanie danych lub ukryć problem z kodem klienta. Poprawa polega na dopasowaniu serializacji do deklarowanego typu oraz na użyciu endpointu, który rzeczywiście obsługuje wymagany format.

Naprawa błędu w aplikacji na laptopie lub komputerze PC

Na komputerze użytkownika warto najpierw powtórzyć operację w innej aplikacji klienckiej albo w trybie diagnostycznym, aby ustalić, czy problem dotyczy konkretnego programu. W przypadku własnego skryptu należy sprawdzić miejsce tworzenia żądania, zwłaszcza automatyczną serializację obiektu i ręczne ustawianie nagłówków. W bibliotekach HTTP częstą przyczyną jest przekazanie słownika jako danych formularza, a następnie ustawienie Content-Type: application/json bez wcześniejszego zakodowania go do JSON. Poprawny klient powinien wykonać serializację i wysłać treść zgodną z typem wskazanym w nagłówku.

Gdy błąd występuje tylko na jednym laptopie lub komputerze, należy porównać wersję programu, ustawienia proxy, rozszerzenia przeglądarki oraz zapisane konfiguracje połączenia. Pomocne jest zapisanie pełnych nagłówków i treści żądania, ale bez ujawniania tokenów uwierzytelniających. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz podzespołów, a w ramach diagnostyki może sprawdzić konfigurację aplikacji, działanie przeglądarki i powtarzalność błędu. Sam kod 415 nie wskazuje jednak na uszkodzenie podzespołu; najczęściej oznacza niezgodność między formatem wysłanych danych a wymaganiami usługi.