请求 headers 的响应 Header 和 accept-encoding 中缺少 content-encoding：gzip、deflate、br（以该精确顺序）用于 HTTPS 请求
Missing content-encoding in Response Header for Request headers with accept-encoding: gzip, deflate, br (in that precise order) for HTTPS Requests
我们正在使用 IBM Portal（8.0 版。0.xx??）。我们有 2 个 IBM 门户服务器位于 2 个 Apache http 服务器后面。
在我们的一个 portlet 中，我们有一个包含以下资源的 jsp 文件：
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.structure.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.theme.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/include.css">
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-1.11.1.min.js"></script>
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-ui.min.js"></script>
当使用最新版本的 Chrome 和 FF 时，在所有情况下，https 请求 header 具有以下令牌：Accept-Encoding:gzip, deflate, br
当 https 响应从服务器返回时，以下资源 不会在响应中返回带有 content-encoding 标记的资源 header（即content-encoding:gzip）
- jquery-ui.structure.min.css
- jquery-ui.theme.min.css
- include.css
因此响应 body 然后显示压缩内容，因为浏览器或接收实体假定资源未被压缩，因此不应用任何解压缩。结果内容当然会呈现为乱码文本。这是由于缺少 content-encoding: gzip 响应 header 令牌。
奇怪的是，其他资源：
- jquery-ui.min.css
- jquery-1.11.1.min.js
jquery-ui.min.js
所有人都返回正确的 content-encoding: gzip安全请求令牌并且响应被正确解压缩。
所有 http 请求 return 返回正常，只有 https 请求对某些资源失败。
我所做的诊断：
我直接打了各个门户服务器都没有问题
安全和不安全的请求。即使浏览器发送
accept-encoding header，服务器都没有响应
content-encoding 表示他们可能没有做的回应
任何压缩（我猜？）
我直接访问了位于门户服务器前面的每个 http 服务器，并且两个服务器 都显示了我所描述的 https 问题以上.
- 我已经在浏览器内部和外部发送 https 请求发送请求并使用 accept-encoding header:
Accept-encoding: gzip 有效 Accept-encoding: gzip, deflate 有效Accept-encoding: gzip, br, deflate 有效Accept-encoding: br, deflate, gzip 有效Accept-encoding: deflate, br, gzip 有效Accept-encoding: gzip, deflate, br 不行
我已将我的 Chrome 版本降级到版本 57，我可以看到 https 的 accept-encoding header 是：gzip, deflate, br, sdch哪个有效。切换回最新版本，https 的 accept-encoding header 更改为：gzip, deflate, br，但失败了。似乎 Google 曾经对所有请求使用 SDCH 数据压缩算法。与“gzip, deflate, br”不同的任何内容都有效！
SDCH 压缩已从 Google Chrome 和其他 Chromium 中移除
产品，版本 59.3。一旦您转到“关于 Chrome”，
版本自动更新到版本 64，Google Chrome 强制执行
默认。由于 sdch 被删除，它留下了有问题的
‘gzip, deflate, br’ 的 accept-encoding 失败了。
FF和Chrome有同样的问题。当我检查
accept-encoding对于http/https，与Chrome相同：
- 对于 http 请求：accept-encoding：
gzip, deflate
对于 https 请求：accept-encoding：gzip, deflate, br（br 仅
对于 https)
但是，FF 允许我更改 accept-encoding 如果我更改
https 的顺序，其他任何内容，即）gzip, br, deflate、IT
成功了！
- 此外，这一切都适用于 IE，因为当我检查
accept-encoding 对于 https 请求，它是‘gzip，deflate’。缺少“br”（brotli 压缩）令牌，因此可以正常工作。
@covener 怀疑的问题是缓存中毒。 httpd.conf 文件中的所有 portlet/applications 都有一个 CacheDisable 指令，除了显示错误的特定 portlet。在包含该 portlet 并重新启动 apache 之后，所有资源都返回了正确的 content-encoding 响应 header，随后解压正常。
感谢大家的帮助。
我们正在使用 IBM Portal（8.0 版。0.xx??）。我们有 2 个 IBM 门户服务器位于 2 个 Apache http 服务器后面。 在我们的一个 portlet 中，我们有一个包含以下资源的 jsp 文件：
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.structure.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.theme.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/include.css">
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-1.11.1.min.js"></script>
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-ui.min.js"></script>
当使用最新版本的 Chrome 和 FF 时，在所有情况下，https 请求 header 具有以下令牌：Accept-Encoding:gzip, deflate, br
当 https 响应从服务器返回时，以下资源 不会在响应中返回带有 content-encoding 标记的资源 header（即content-encoding:gzip）
- jquery-ui.structure.min.css
- jquery-ui.theme.min.css
- include.css
因此响应 body 然后显示压缩内容，因为浏览器或接收实体假定资源未被压缩，因此不应用任何解压缩。结果内容当然会呈现为乱码文本。这是由于缺少 content-encoding: gzip 响应 header 令牌。
奇怪的是，其他资源：
- jquery-ui.min.css
- jquery-1.11.1.min.js
jquery-ui.min.js
所有人都返回正确的
content-encoding: gzip安全请求令牌并且响应被正确解压缩。
所有 http 请求 return 返回正常，只有 https 请求对某些资源失败。
我所做的诊断：
我直接打了各个门户服务器都没有问题 安全和不安全的请求。即使浏览器发送 accept-encoding header，服务器都没有响应 content-encoding 表示他们可能没有做的回应 任何压缩（我猜？）
我直接访问了位于门户服务器前面的每个 http 服务器，并且两个服务器 都显示了我所描述的 https 问题以上.
- 我已经在浏览器内部和外部发送 https 请求发送请求并使用 accept-encoding header:
Accept-encoding: gzip有效Accept-encoding: gzip, deflate有效Accept-encoding: gzip, br, deflate有效Accept-encoding: br, deflate, gzip有效Accept-encoding: deflate, br, gzip有效Accept-encoding: gzip, deflate, br不行我已将我的 Chrome 版本降级到版本 57，我可以看到 https 的 accept-encoding header 是：
gzip, deflate, br, sdch哪个有效。切换回最新版本，https 的 accept-encoding header 更改为：gzip, deflate, br，但失败了。似乎 Google 曾经对所有请求使用 SDCH 数据压缩算法。与“gzip, deflate, br”不同的任何内容都有效！SDCH 压缩已从 Google Chrome 和其他 Chromium 中移除 产品，版本 59.3。一旦您转到“关于 Chrome”， 版本自动更新到版本 64，Google Chrome 强制执行 默认。由于 sdch 被删除，它留下了有问题的 ‘
gzip, deflate, br’ 的 accept-encoding 失败了。FF和Chrome有同样的问题。当我检查 accept-encoding对于http/https，与Chrome相同：
- 对于 http 请求：accept-encoding：
gzip, deflate 对于 https 请求：accept-encoding：
gzip, deflate, br（br 仅 对于 https)但是，FF 允许我更改 accept-encoding 如果我更改 https 的顺序，其他任何内容，即）
gzip, br, deflate、IT 成功了！- 此外，这一切都适用于 IE，因为当我检查 accept-encoding 对于 https 请求，它是‘gzip，deflate’。缺少“br”（brotli 压缩）令牌，因此可以正常工作。
@covener 怀疑的问题是缓存中毒。 httpd.conf 文件中的所有 portlet/applications 都有一个 CacheDisable 指令，除了显示错误的特定 portlet。在包含该 portlet 并重新启动 apache 之后，所有资源都返回了正确的 content-encoding 响应 header，随后解压正常。 感谢大家的帮助。