Ich konnte in den HTTP-Spezifikationen keine Dokumentation finden, die angibt, ob die Generierung einer HTTP-Antwort akzeptabel ist, einschließlich einer für Menschen lesbaren Fehlermeldung (z. B. Inhaltstyp: Text / Nur), wenn ein HTTP-Client eine ungültige HTTP-Anforderung gestellt hat. und einen Anforderungsheader angegeben, der die zulässigen Antwortinhaltstypen mithilfe eines Accept-Headers einschränkt.

Stellen Sie sich einen REST-Webdienst-Client vor, der eine ungültige GET-Anforderung an "http: // myhost / validpath? IllegalRequestParameter = rubbish" ausgibt und einen Anforderungsheader "Accept: application / xml" oder "Accept: application / vnd.ms-excel" enthält. .

Der Server würde mit einem HTTP-Statuscode in der 4XX-Reihe (in diesem Fall "400 Bad Request") antworten. Aber wie kann der Dienst dem Kunden Informationen über die Fehlerursache übermitteln?

Ich sehe die folgenden Optionen:

Erstellen Sie eine Klartext-Fehlermeldung im Inhalt der HTTP-Antwort. Legen Sie den Antwortheader "Content-type: text / plain" fest und fügen Sie dem Antwortinhalt eine beschreibende Fehlermeldung hinzu. Dies würde jedoch die "Accept" -Einschränkung des HTTP-Clients aufheben.

Fügen Sie keinen HTTP-Antwortinhalt hinzu. Dies ist eindeutig gültig, aber nicht sehr hilfreich für den Client, der nur weiß, dass ein "Client-Fehler" aufgetreten ist, aber nicht weiß, warum (und den Grund in einer Client-Protokolldatei angibt).

Versuchen Sie, eine Fehlermeldung in einen "Accept'able" MIME-Typ umzuwandeln. Dies ist selten möglich. Selbst wenn die Fehlermeldung als gültiger application / xml-Typ erstellt werden könnte, würde dies wahrscheinlich einen Web-Service-Vertrag (z. B. XML-Schema-Konformität) brechen.

Meine Frage ist: Wird die obige Situation durch bestehende HTTP-Spezifikationen / -Standards geregelt?

Verweise:

Definitionen des HTTP-Statuscodes:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlFelddefinitionen für HTTP-Headerhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html