0

我正在构建一个 Web 应用程序，它可以通过PUT,POST和JSON 格式接受资源表示PATCH。x-www-form-urlencoded如果我收到另一种格式的请求正文，我想发送一个415响应，以及一些声明我接受哪些格式的附加数据（以类似于405响应的强制Allow:标头的方式）。我在HTTP 406 和 415 错误代码的一个答案中看到，其中回答的人不知道是否定义了这样的机制，RFC 2616 在这方面没有提及任何内容，一些粗略的谷歌搜索也没有出现。

Accept:即使将其定义为请求标头，我也想使用。将其重新用于此响应似乎是最合适的。人家同意吗？有人有更好的建议吗？

编辑：我在发送“415 unsupported media type”时发现指定支持的媒体类型，它专门询问是否有这个标准。正确且被接受的答案基本上是no，但那里的受访者也和我有同样的想法，即 Accept 将是一个很好的标题，可以用来提供这些信息。这促使Julian Reschke向 HTTP 工作组发送了一条消息，询问是否应该定义在响应中发送标头的含义。那封电子邮件只收到了一封回复，他们同意它是必要的，并且接受似乎是合适的。Accept:

请注意，我不是在询问是否允许我发送 Accept 标头，任何标头都可以在任一方向发送，但只有规范中定义的标头对中介具有意义（语义），并且任何未加前缀的意外标头withX-可能会与 HTTP 的未来版本发生冲突。这不打扰我。

4

3 回答 3

1

正如你所说，Accept是一个请求标头。在响应中使用它是错误的。

引用维基百科，

内容协商是 HTTP 规范中定义的一种机制，它可以在同一个 URI 上提供文档的不同版本（或更一般地，资源表示），以便用户代理可以指定哪个版本最适合他们的能力。

所以是客户在请求中说他可以使用什么媒体类型Accept。如果服务器不能提供这种媒体类型，他会回复406 Not Acceptable。

由于客户端必须能够处理所请求资源的返回表示，它应该指定它可以理解的媒体类型。它可以指定多种媒体类型：

Accept: application/json, application/xml, x-www-form-urlencoded

如果客户端真的想接受任何媒体类型，它可以设置

Accept: */*

即使对于这样的请求，服务器也会设置适当的Content-Type响应头。

于 2012-11-08T08:03:38.927 回答
0

您收到无法识别的 Content-Type 很可能来自当前正在为您的服务实现客户端的开发人员。由于不存在服务器宣传其支持的内容类型的机制，您不妨在消息正文中提及您支持的类型。

于 2012-11-08T08:19:11.220 回答
0

我不知道执行此操作的任何标准机制，但您可以稍微重新调整 Alternates 标头http://www.ietf.org/rfc/rfc2295.txt的用途来做您想做的事情。

于 2012-11-09T12:33:32.733 回答