请求指定无效Content-Encoding标头的适当HTTP状态代码？

Question

如果客户端发送HTTP请求并指定无法由服务器解码的Content-Encoding标头,应返回什么状态代码？

例

客户端将JSON数据POST到REST资源,并使用gzip编码对实体主体进行编码.但是,服务器只能解码DEFLATE编码,因为它在服务器学校的gzip类失败了.

应该返回什么HTTP响应代码？我会说415不支持的媒体类型,但它不是实体的内容类型是问题 - 它是否则支持的实体主体的编码.

哪个更合适:415？400？也许是自定义响应代码？

---

附录:当然,我已经彻底检查了rfc2616.如果答案在那里,我可能需要一些新的矫正眼镜,但我不相信它.

---

更新:

这与发送可能对客户端不可接受的响应无关.问题是客户端在服务器无法理解的编码中向服务器发送可能是或可能不是有效媒体类型的服务器(根据Content-Encoding客户端与请求消息打包在一起的头部).

这是一个边缘情况,在处理浏览器用户代理时不会遇到,但它可能会在REST API中出现,接受实体主体来创建/修改资源.

Answer 1

正如我正在阅读它,415 Unsupported Media Type听起来最合适.

来自RFC 2616:

10.4.16 415不支持的媒体类型

服务器拒绝为请求提供服务,因为请求的实体采用所请求方法的请求资源不支持的格式.

是的,文本部分说"媒体类型"而不是"编码",但实际描述中没有提到任何区别.

新的热点,RFC 7231,甚至是明确的:

6.5.13.415不支持的媒体类型

415(不支持的媒体类型)状态代码表示
源服务器拒绝为请求提供服务,因为有效负载
的格式不是此方法在目标资源上支持的格式.
格式问题可能是由于请求指示了
Content-Type或Content-Encoding,或者是由于
直接检查数据.

Answer 2

他们应该把关于谁想要成为百万富翁的最后一个问题做出决定!

好吧,浏览器发出服务器无法提供服务的请求,因为客户端提供的信息格式是服务器无法处理的.但是,这不是服务器因为不支持客户端提供的数据而导致的错误,因为客户端没有收听服务器的Acccept-*标头并以不适当的编码方式提供数据.这将使它成为客户端错误(400系列错误代码).

• 我的第一直觉是400 Bad Request是这种情况下的适当回应.
• 405 Method Not Allowed不正确,因为它引用的HTTP动词是不允许的动词.
• 406 Not Acceptable看起来可能有承诺,但它指的是服务器无法向客户端提供满足其发送的Accept-*请求标头的数据.这似乎不适合你的情况.
• 412前提条件失败的定义相当模糊.这可能是合适的,但我不会赌它.
• 415不支持的媒体类型不正确,因为它不是被拒绝的数据类型,而是编码格式.

之后我们进入非标准响应代码领域.

• 422 Unprocessable Entity描述了一个响应,如果请求格式正确但是在某种程度上它在语义上是不正确的,则应该返回该响应.这看起来很合适,但它是HTTP的WebDAV扩展而不是标准.

鉴于上述情况,我个人会选择400 Bad Request.如果任何其他HTTP专家有更好的候选人,我会听取他们的意见.;)

更新:我以前一直在维基百科的页面上引用HTTP状态.虽然那里的信息似乎是准确的,但它也不够全面.查看来自W3C的规范提供了有关HTTP 406的更多信息,并且它让我认为406可能是正确的代码.

10.4.7 406不可接受

由请求标识的资源仅能够根据请求中发送的接受报头生成具有不可接受的内容特征的响应实体.

除非它是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.

如果响应可能是不可接受的,则用户代理应该暂时停止接收更多数据并查询用户以决定进一步的操作.

虽然它确实明确地提到了Content-Type标题,但是措辞提到了"实体特征",你可以把它看作覆盖GZIP和DEFLATE压缩等内容.

值得注意的一点是,规范说,按原样发送数据可能是合适的,连同标题一起告诉客户端它的格式和使用的编码,然后留给客户端进行整理. .因此,如果客户端发送一个标题表明它接受GZIP压缩,但服务器只能生成一个DEFLATE响应,那么发送它与标题说它是DEFLATE应该没问题(取决于上下文).

• 客户:给我一个GZIPPED页面.
• 服务器:对不起,没办法.我可以为你包装它.这是DEFLATE打包页面.这对你好吗？
• 客户:Welllll ......我真的不想要DEFLATE,但我可以解码它,所以我会接受它.

(要么)

• 客户:我想我必须与我的用户清楚.坚持,稍等.