如果客户端发送一个HTTP请求，并指定一个Content-Encoding头不能被服务器解码应该返回什么状态代码？
例
客户端的POST JSON数据到REST资源并编码使用gzip的编码实体主体。 但是，因为它在服务器学校未能gzip的类服务器只能解码DEFLATE的代号。
什么HTTP响应代码应返回？ 我会说415不支持的媒体类型 ，但它不是实体的Content-Type，这是问题-它是支持其它实体主体的编码。
这是比较合适的：415？ 400？ 也许一个自定义的响应代码？
附录：我有，当然，彻底检查RFC2616。 如果答案是有可能我需要一些新的矫正眼镜，但我不认为它是。
更新：
这无关与发送，可能是无法接受的客户端的响应。 的问题是，客户端发送什么可以是或可以不是在编码有效的媒体类型的服务器无法理解（按照服务器Content-Encoding报头中的客户端与所述请求消息封装）。
这是一个边缘的情况下，用浏览器的用户代理打交道时不会遇到，但它可以在REST API的突然出现用工单位机构创建/修改资源。
因为我读它， 415 Unsupported Media Type听起来就像是最合适的。
从RFC 2616：
10.4.16 415不支持的媒体类型
服务器拒绝，因为请求的实体是不被请求方式所请求的资源支持的格式来请求服务。
是啊，正文部分称“媒体类型”，而不是“编码”，但实际的描述不包括区分任何提及。
新的辣味， RFC 7231 ，甚至明确一下：
6.5.13。 415不支持的媒体类型
415（不支持的媒体类型）状态代码表示
起源服务器拒绝服务，因为有效载荷的要求
是不是对目标资源这种方法支持的格式。
格式问题可能是由于请求的指示
Content-Type或内容编码 ，或作为检查的结果
数据直接。
他们应该是在最后一个问题谁想成为百万富翁！
那么浏览器所做的服务器无法提供服务，因为客户端所提供的信息是不能被服务器处理的格式的请求。 然而，这并不是服务器的，不支持客户端所提供的数据错误，这是客户对不听服务器的Acccept- *头和不适当的编码提供数据故障。 这将使它成为一个客户端错误（400系列错误代码）。
之后，我们进入的非标准的响应代码的境界。
鉴于上述情况，我个人选择400错误的请求。 如果任何其他HTTP专家有更好的人选，虽然，我会听取他们的意见，而不是。 ;）
更新 ：我以前一直从他们的维基百科页面引用HTTP状态。 虽然信息似乎是准确的，它也比彻底的少。 看着从规格W3C给出了HTTP 406更大量的信息，它的领导让我觉得406可能是毕竟正确的代码。
10.4.7 406不可接受
该请求所标识的资源只能能够产生具有根据在请求中发送的接受报头，内容无法接收响应实体。
除非它是一个HEAD请求，响应应该包括含有的可用的实体特征和位置（S），用户从该用户或代理可以选择一个最合适的列表的实体。 实体格式由在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.如果响应可能是不可接受的，用户代理应该暂时停止接收更多数据，并询问用户进一步行动的决定。
虽然它明确提到的Content-Type头，措辞提到了“实体特性”，你可以理解为适用的东西像GZIP与DEFLATE压缩。
有一两件事值得一提的是，规范说，它可能是适当的，只是用头发送数据，沿着告诉它什么格式的客户，什么编码它使用了，只是离开它的客户进行梳理。 因此，如果客户端发送标题表明它接受GZIP压缩，但服务器只能产生与DEFLATE的响应，然后发送与头说沿着它的DEFLATE应该没问题（根据上下文）。
（要么）
