我正在构建一个Web应用程序，它可以通过PUT，POST和PATCH以x-www-form-urlencoded和JSON格式接受资源表示。如果我收到另一种格式的请求正文，我想发送一个415响应，以及一些其他数据，声明我接受的格式（与405响应强制{{1标头）。我在HTTP 406 and 415 error codes的一个答案中看到，回答的人不知道是否有这样的机制，RFC 2616在这方面没有提到任何内容，而且一些粗略的谷歌搜索也没有。
我想使用Allow:，即使它被定义为请求标头。似乎最合适的只是重复使用它来做出这种反应。伙计们同意吗？有人有更好的建议吗？
编辑：我后来发现Specify supported media types when sending "415 unsupported media type"，具体询问是否有标准。正确和接受的答案基本上是不，但那里的响应者也有与我相同的想法，Accept将是用于提供此信息的良好标题。这提示a message从Julian Reschke向HTTP工作组询问是否应该定义在响应中发送Accept:标头应该是什么意思。该电子邮件只收到一个回复，同意这是必要的，而Accept似乎是合适的。
请注意，我不是在问我是否允许发送Accept标头，允许在任一方向发送任何标头，但只有那些在规范中定义的标头意味着< / em>（语义）到中介，以及任何没有前缀Accept:的意外标题可能会与未来的HTTP版本冲突。这不会打扰我。
答案 0 :(得分：1)
正如您所说，Accept是请求标头。在响应中使用它是错误。
内容协商是HTTP规范中定义的一种机制，可以在同一URI上提供不同版本的文档（或更一般地说，资源表示），以便用户代理可以指定哪个版本符合其功能最好。
因此，客户在请求中说出了他可以Accept的媒体类型。如果服务器无法提供此媒体类型，则会使用406 Not Acceptable进行响应。
由于客户端必须能够处理所请求资源的返回表示，因此应指定它可以理解的媒体类型。它可以指定多种媒体类型：
Accept: application/json, application/xml, x-www-form-urlencoded
如果客户真的想接受任何媒体类型，可以设置
Accept: */*
即使是这样的请求，服务器也会设置正确的Content-Type响应标头。
答案 1 :(得分：0)
您收到无法识别的Content-Type很可能来自目前正在为您的服务实施客户端的开发人员。由于服务器不存在通告其支持的内容类型的机制，因此您可以在消息正文中提及您支持的类型。
答案 2 :(得分：0)
我不知道有任何标准机制可以执行此操作，但您可以稍微重新使用Alternates标头http://www.ietf.org/rfc/rfc2295.txt来完成您想要的操作。