向未指定 Accept-Encoding: gzip 的客户端发送经过 gzip 压缩的响应是否是一个错误？答案

【问题标题】：is it a bug to send response gzip-compressed to clients that doesn't specify Accept-Encoding: gzip?向未指定 Accept-Encoding: gzip 的客户端发送经过 gzip 压缩的响应是否是一个错误？
【发布时间】：2018-11-03 11:31:43
【问题描述】：

如果将内容 gzip 压缩发送到未指定 Accept-Encoding: gzip 的客户端，是否是服务器中的错误？它是否违反了 http 规范？还是合法的？

我很好奇，因为 https://www.amazon.com 总是发送 gzip 压缩的内容，无论 Accept-Encoding 标头如何，作为一个简单的确认测试：

$ curl https://www.amazon.com
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

$ curl https://www.amazon.com -I
HTTP/2 405
content-type: text/html; charset=UTF-8
server: Server
date: Sat, 03 Nov 2018 11:27:35 GMT
set-cookie: skin=noskin; path=/; domain=.amazon.com
strict-transport-security: max-age=47474747; includeSubDomains; preload
x-amz-id-1: 2M3HZHHA9J21D3MTHH4K
allow: POST, GET
vary: Accept-Encoding,User-Agent,X-Amazon-CDN-Cache
content-encoding: gzip
x-amz-rid: 2M3HZHHA9J21D3MTHH4K
x-frame-options: SAMEORIGIN
x-cache: Error from cloudfront
via: 1.1 1cc4305a3ce000ca199328864ca1c98e.cloudfront.net (CloudFront)
x-amz-cf-id: OKz61IdKmCBfC97pPg-zmDhQnJzK3THXL2iYwegU5EtDaRf6yjBGzw==

curl 抱怨它在这里接收二进制数据，因为它没有响应 HTML，而是 gzip 压缩的 html，它是二进制数据。要实际查看 html，请添加 --compressed 参数，该参数告诉 curl 添加标头 Accept-Encoding: gzip, deflate 并自动解压缩响应。

【问题讨论】：

标签： http

【解决方案1】：

没有 Accept-Encoding 标头字段的请求意味着用户代理对内容编码没有偏好。虽然这允许服务器在响应中使用任何内容编码，但这并不意味着用户代理将能够正确处理所有编码。

-- https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.4.p.4

【讨论】：

猜猜这意味着no，规范允许这种行为^^ 同一份文件还指出An "identity" token is used as a synonym for "no encoding" - 实际上，curl -H "Accept-Encoding: identity" https://www.amazon.com 关闭了来自 amazon.com 的压缩