Nie udało mi się znaleźć żadnej dokumentacji w specyfikacjach HTTP, która określałaby, czy dopuszczalne jest wygenerowanie odpowiedzi HTTP, w tym czytelny dla człowieka komunikat o błędzie (np. Typ zawartości: tekst / zwykły), jeśli klient HTTP wykonał nieprawidłowe żądanie HTTP, i określił nagłówek żądania, który ogranicza akceptowalne typy treści odpowiedzi za pomocą nagłówka akceptacji.

Wyobraź sobie klienta usługi WWW REST, który wysyła nieprawidłowe żądanie GET do „http: // myhost / validpath? InvalidRequestParameter = rubbish”, w tym nagłówek żądania „Accept: application / xml” lub „Accept: application / vnd.ms-excel” .

Serwer odpowiedziałby kodem stanu HTTP w serii 4XX (w tym przypadku „400 Bad Request”). Ale w jaki sposób usługa mogłaby przekazać klientowi informacje o przyczynie błędu?

Widzę następujące opcje:

Utwórz komunikat o błędzie zwykłego tekstu w treści odpowiedzi HTTP. Ustaw nagłówek odpowiedzi „Content-type: text / plain” i dołącz opisowy komunikat o błędzie do treści odpowiedzi. Przerwałoby to jednak ograniczenie „Akceptuj” klienta HTTP.

Nie dołączaj treści odpowiedzi HTTP. Jest to wyraźnie ważne, ale nie bardzo pomocne dla klienta, który po prostu wie, że wystąpił „błąd klienta”, ale nie ma możliwości dowiedzenia się dlaczego (i raportowania przyczyny w pliku dziennika klienta).

Spróbuj przekonwertować komunikat o błędzie na typ MIME „Akceptujący”. To jest rzadko możliwe. Nawet jeśli komunikat o błędzie mógłby zostać skonstruowany jako poprawny typ aplikacji / xml, prawdopodobnie złamałby umowę o świadczenie usług internetowych (np. Zgodność ze schematem XML).

Moje pytanie brzmi: czy powyższa sytuacja jest regulowana przez istniejące specyfikacje / standardy HTTP?

Referencje:

Definicje kodu stanu HTTP:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlDefinicje pól nagłówka HTTPhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html