问题
假设我们在磁盘上有一个压缩档案，例如file.tar.gz，应该按原样提供。
该文件随附了Content-Type: application/gzip，但由于某种原因，服务器还添加了Content-Encoding: gzip标头，尽管它确实不是应用任何额外的即时压缩（因此不 mod_deflate或类似）。
因此，一些用户代理（例如 Python 的requests和urllib3）将自动解压 gzip 文件，因此，下载后，我们得到的是file.tar，而不是file.tar.gz。
例子
一个例子是 Django 开发服务器，它Content-Encoding根据文件名添加一个标头，如下图所示这里。
另一个示例是与 AWS S3 结合使用。如果使用(v1.12.3)django-storages将 gzip 文件上传到 S3 存储桶，则会将标头添加到文件元数据中，如下所示django-storagesContent-Encoding: gzip这里。从 S3 下载该文件时，Content-Encoding元数据将添加到下载响应标头中。
问题
这是可以接受的服务器行为吗？或者服务器是否应该考虑破碎的？
我发现了什么
此摘录自rfc7231似乎表明这种行为不是可接受：
... 内容编码主要用于允许压缩表示的数据而不会丢失其底层媒体类型的标识。... 如果媒体类型包含固有编码，例如始终压缩的数据格式，则该编码将不会在内容编码中重述...
尽管“主要”暗示可能还有其他用途。
以下是同样的事情，只是措辞略有不同，Mozilla：
... 如果原始媒体以某种方式编码（例如 zip 文件），则此信息将不会包含在标题中
Content-Encoding。
然而，rfc7231然后继续说以下内容，（我认为）这表明了这种行为能可以接受：
...同样，原始服务器可能会选择将相同的数据发布为多种表示形式，这些表示形式仅在于编码是否定义为
Content-Type或的一部分而有所不同Content-Encoding，因为某些用户代理在处理每个响应时会表现不同（例如，打开“另存为...”对话框而不是自动解压缩和呈现内容）。
如果这是可接受的服务器行为，那么我想我们的用户代理需要考虑到这一点。