如果客户端以不受支持的媒体类型向 HTTP 服务器发送数据，服务器会以“415 unsupported media type”状态回复。但是如何告诉客户端支持哪些媒体类型呢？是否有标准或至少推荐的方法？还是只是将其作为文本写入响应正文？
【问题讨论】：
标签： http rest http-status-codes httpresponse content-negotiation
tl;博士;
将生成的代理类编辑为继承自Microsoft.Web.Services3.WebServicesClientProtocol**。
我在解决此错误时遇到了这个问题，所以我想我会帮助下一个可能遇到这里的人，尽管不确定它是否回答了所述问题。当我不得不接管一个使用 WSE 和 MTOM 编码的现有解决方案时，我遇到了这个错误。这是一个调用 Web 服务的 Windows 客户端。
到了这一点，客户端正在调用 Web 服务，它会抛出该错误。
对我来说有助于解决该错误的事情是检查显然默认生成为从System.Web.Services.Protocols.SoapHttpClientProtocol 继承的 Web 服务代理类。
从本质上讲，这意味着它实际上并没有使用 WSE3。
无论如何我手动编辑了代理并将其更改为从Microsoft.Web.Services3.WebServicesClientProtocol继承。
顺便说一句，要在 VS 中查看生成的代理类，请单击 Web 参考，然后单击“显示所有文件”工具栏按钮。 reference.cs 是一个快乐的地方！
希望对你有帮助。
【讨论】：
在他的书“HTTP Developer's Handbook”（第 81 页）中，Chris Shiflett 解释了 415 的含义，然后他说：“HTTP 响应内容中使用的媒体类型应在 Content-Type 实体标头中指示。 "
1) 那么 Content-Type 是一个可能的答案吗？它可能是接受的内容类型的逗号分隔列表。这种可能性的明显问题是 Content-Type 是实体标头而不是响应标头。
2) 或者这是书中的错字？他真的是想说“HTTP 请求”吗？
【讨论】：
我相信您可以使用OPTIONS Http 动词来做到这一点。
如果您的场景适合某个用例，也可以使用状态码 300 Multiple Choices。如果他们发送带有application/xml 的Accept 标头的请求并且您仅支持text/plain 并且该表示存在于不同的URL 中，那么您可以使用300 响应并且在Location 标头中该表示的URL。我意识到这可能不完全符合您的问题，但这是另一种可能的选择。
来自 HTTP 规范：
10.4.7 406 不可接受
请求标识的资源只能生成响应实体，其内容特征根据请求中发送的accept headers是不可接受的。
除非它是一个 HEAD 请求，否则响应应该包含一个实体，该实体包含一个可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由 Content-Type 标头字段中给出的媒体类型指定。根据用户代理的格式和能力，可以自动选择最合适的选项。但是，该规范没有为这种自动选择定义任何标准。
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable.
【讨论】：
415 响应中使用此标头。通常OPTIONS只是用来找出支持哪些方法。
406 无关紧要，因为这与 response 的类型不匹配有关。 415 是当服务器无法处理 request 正文中的数据类型时得到的。 （我刚刚在我正在开发的 RESTful web 服务的上下文中处理这个问题，所以我确定这是正确的解释。）问题是服务器无法处理消息并且客户端已经在发送它；错误是唯一的可能性（并且没有办法给出正确的机器可读方式来说明什么会起作用）。
根本没有关于在这种情况下做什么的规范，所以希望实现无处不在。 （如果服务器的响应包含类似Accept: 标头之类的东西，那将是明智的，因为如果当前方向错误，它具有几乎正确的语义。）
【讨论】：
Accept 从服务器到客户端的标头将是我正在寻找的。我期待 HTTP 1.2 ;-)