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)
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.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.
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.
Accept-encoding: gzip works Accept-encoding: gzip, deflate worksAccept-encoding: gzip, br, deflate worksAccept-encoding: br, deflate, gzip worksAccept-encoding: deflate, br, gzip worksAccept-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:
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!
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.