1

我们正在使用 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 请求标头都具有以下标记：Accept-Encoding:gzip, deflate, br

当 https 响应从服务器返回时，以下资源不会在响应标头中返回内容编码令牌（即content-encoding:gzip）

  • jquery-ui.structure.min.css
  • jquery-ui.theme.min.css
  • 包含.css

因此响应正文显示压缩内容，因为浏览器或接收实体假定资源尚未压缩，因此不应用任何解压缩。然后，生成的内容当然会呈现为乱码。这是由于缺少content-encoding: gzip响应标头令牌。

奇怪的是，其他资源：

  • jquery-ui.min.css
  • jquery-1.11.1.min.js

  • jquery-ui.min.js

    content-encoding: gzip所有返回的安全请求都带有正确的令牌，并且响应已正确解压缩。

所有 http 请求都返回正常，只有某些资源失败的 https 请求。

我所做的诊断：

  • 我直接访问了每个门户服务器，安全和不安全请求都没有问题。即使浏览器发送了一个接受编码标头，服务器都没有响应内容编码响应，这意味着它们可能没有进行任何压缩（我猜？）

  • 我已经直接访问了位于门户服务器前面的每个 http 服务器，并且两台服务器都显示了 https 的问题，如上所述。

  • 我已经在浏览器内部和外部发送了 https 请求，发送请求并使用了 accept-encoding 标头：
  • 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 的接受编码标头是：gzip, deflate, br, sdch哪个有效。切换回最新版本，https 的 accept-encoding 标头更改为 : gzip, deflate, br，但失败。谷歌似乎曾经对所有请求使用 SDCH 数据压缩算法。任何与 '<code>gzip, deflate, br' 不同的东西都可以！

  • 在 59.3 版中，从 Google Chrome 和其他 Chromium 产品中删除了 SDCH 压缩。只要您转到“关于 Chrome”，版本就会自动更新到 Google Chrome 默认强制执行的 64 版。由于 sdch 被删除，它留下了 '<code>gzip, deflate, br' 的有问题的接受编码，它失败了。

  • FF 和 Chrome 有同样的问题。当我检查 http/https 的接受编码时，它与 Chrome 相同：

  • 对于 http 请求：接受编码：gzip, deflate

  • 对于 https 请求：accept-encoding: gzip, deflate, br（br 仅适用于 https）

  • 但是，FF 允许我更改接受编码，如果我将 https 的顺序更改为其他任何内容，即）gzip, br, deflate，它可以工作！

  • 此外，这一切都适用于 IE，因为当我检查 https 请求的接受编码时，它是“gzip，deflate”。缺少“br”（brotli 压缩）令牌，因此它可以工作。
4

1 回答 1

0

@covener 怀疑的问题是缓存中毒。我们的 httpd.conf 文件中的所有 portlet/应用程序都有一个 CacheDisable 指令，除了显示错误的特定 portlet。在包含该 portlet 并重新启动 apache 后，所有资源都以正确的内容编码响应标头返回，随后解压缩正常。感谢所有的帮助。

于 2018-05-17T01:56:37.927 回答