I could not find any documentation in the HTTP specifications that determine whether it is acceptable to generate an HTTP response, include a human readable message (e.g. content-type: text / plain) if the HTTP client invalidated the HTTP, and set a request header that restricts the allowed response content types using the accept header.
Imagine that the REST web service client issuing an invalid GET request is "http: // myhost / validpath? IllegalRequestParameter = garbage" and includes the request header "Accept: application / xml" or "Accept: application / vnd.ms" -excel "
The server will respond with an HTTP status code in the 4XX series ("400 Bad Request", in this case). But how can the service convey information to the client about the cause of the error?
I see the following options:
Create an error message in the text of the HTTP response. Set the response header to “Content Type: Text / Plain” and include a descriptive error message in the response content. This, however, violates the HTTP Accept client limit.
Do not include HTTP response content. This is clearly relevant, but not very useful for a client who simply knows that a "client error" has occurred, but does not know why (and reports the reason in the client's log file).
Try forcing the error message to the MIME type "Acceptable". This is rarely possible. Even if the error message can be constructed as a valid type of application / xml, it is likely to violate the web service contract (for example, XML schema compliance).
My question is: Is the situation described above a standard spec / HTTP standard?
Literature:
source share