如果 HTTP 客户端发出了无效的 HTTP 请求，我无法在 HTTP 规范中找到任何文档来管理是否可以接受生成 HTTP 响应，包括人类可读的错误消息（例如内容类型：文本/纯文本），并指定了一个请求标头，该标头使用接受标头限制可接受的响应内容类型。
想象一个 REST Web 服务客户端向“http://myhost/validpath?illegalRequestParameter=rubbish”发出无效的 GET 请求，并包含请求标头“Accept: application/xml”或“Accept: application/vnd.ms-excel” .
服务器将使用 4XX 系列中的 HTTP 状态代码（在本例中为“400 Bad Request”）进行响应。但是服务如何能够向客户端传达有关错误原因的信息？
我看到以下选项：
在 HTTP 响应内容中创建明文错误消息。设置响应头“内容类型：文本/纯文本”，并在响应内容中包含描述性错误消息。但是，这会打破 HTTP 客户端的“接受”限制。
不要包含 HTTP 响应内容。这显然是有效的，但对于只知道发生“客户端错误”但无法知道原因（并在客户端日志文件中报告原因）的客户端来说不是很有帮助。
尝试将错误消息强制转换为“可接受的”MIME 类型。这是很少可能的。即使可以将错误消息构造为有效的应用程序/xml 类型，它也可能会破坏 Web 服务合同（例如 XML 模式一致性）。
我的问题是：上述情况是否受现有 HTTP 规范/标准的约束？
参考：