Missing content-encoding in Response Header for Request headers with accept-encoding: gzip, deflate, br (in that precise order) for HTTPS Requests

We are using IBM Portal (version 8.0.0.xx??). We have 2 IBM portal servers sitting behind 2 Apache http servers. In one of our portlets, we have a jsp file that includes the following resources:

<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>

When using the latest versions of Chrome and FF, in all cases, the https request header has the following token: Accept-Encoding:gzip, deflate, br

When the https response comes back from the server, the following resources do not come back with a content-encoding token in the response header (i.e content-encoding:gzip)

• jquery-ui.structure.min.css
• jquery-ui.theme.min.css
• include.css

So the response body then shows compressed content since the browser, or receiving entity, assumes the resource has not been compressed and therefore does not apply any uncompression. The resulting content is then ofcourse rendered as garbled text. This is due to the absence of the content-encoding: gzip response header token.

Strangely, the other resources:

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

• jquery-ui.min.js

  All come back with a correct content-encoding: gzip token for secure requests and the response is uncompressed correctly.

All http requests return back fine, its only the https requests that fail for some resources.

What I've done to diagnose:

• I’ve hit each portal server directly and there are no problems for both secure and unsecure requests. Even though the browser sends an accept-encoding header, the servers both respond with no content-encoding response which means that they are likely not doing any compression (I'm guessing?)

• I’ve hit each http server that sit in front of the portal servers directly, and both servers show the problems for https as I've described above.

• I’ve sent https requests inside and outside the browser sending requests and playing around with the accept-encoding header:
• Accept-encoding: gzip works
• Accept-encoding: gzip, deflate works
• Accept-encoding: gzip, br, deflate works
• Accept-encoding: br, deflate, gzip works
• Accept-encoding: deflate, br, gzip works

• Accept-encoding: gzip, deflate, br doesn’t work

• I’ve downgraded my version of Chrome to version 57 and I can see that the accept-encoding header for https was: gzip, deflate, br, sdch which works. Switching back to the latest version, the accept-encoding header for https changes to : gzip, deflate, br, which fails. It seems Google used to use the SDCH data compression algorithm for all requests. Anything different from ‘gzip, deflate, br’ works!

• SDCH compression was removed from Google Chrome, and other Chromium products, in version 59.3. As soon as you go to ‘About Chrome’, the version auto updates to version 64 which Google Chrome enforces by default. Since sdch is removed, it leaves the offending accept-encoding of ‘gzip, deflate, br’ which fails.

• FF has the same problem as Chrome. When I inspected the accept-encoding for http/https, it is the same as Chrome:

• For http requests: accept-encoding: gzip, deflate

• For https requests: accept-encoding: gzip, deflate, br (br is only for https)

• However, FF allowed me to change the accept-encoding and if I change the order for https, to anything else i.e) gzip, br, deflate, IT WORKS!

• Also, this all works in IE, because when I inspected the accept-encoding for https requests, it is ‘gzip, deflate’. The ‘br’ (brotli compression) token is missing and hence it works.

The problem as suspected by @covener, was poisoned cache. All of the portlet/applications within our httpd.conf file had a CacheDisable directive except for the particular portlet that was exhibiting the errors. After including that portlet and restarting apache, the resources all came back with a proper content-encoding response header and subsequently decompressed fine. Thanks for all the help guys.